The message used to warn about preserve_old_lib* is not really matching the todays reality now that FEATURES="preserved-libs" is enabled by default. upstream.workaround 4 sys-fs/udev/udev-206-r1.ebuild: Upstream ABI change workaround on line: 410 sys-fs/udev/udev-206-r1.ebuild: Upstream ABI change workaround on line: 503 sys-fs/udev/udev-9999.ebuild: Upstream ABI change workaround on line: 410 sys-fs/udev/udev-9999.ebuild: Upstream ABI change workaround on line: 503 After seeing those, it's not immediately clear what should be done and accordingly, developers are ignoring it. Please replace the message with something like: "preserve_old_lib should be removed in favour of preserved-libs on line: XXX" And I'm not sure if it should be categorized as 'upstream.workaround' anymore either?
Created attachment 355398 [details, diff] Improve preserve_old_lib repoman check This should do it -- and match the other existing checks in style
Thanks, this is in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=49cbc17bf7b99be586e158c1bd588cfe91dfe58c
This is fixed in 2.1.13.7 and 2.2.0_alpha196.
Repoman should not report that preserve_old_lib is deprecated, since preserve-libs is covered by PMS.
Patch posted for review: https://archives.gentoo.org/gentoo-portage-dev/message/f3434d86197a3c4cf8f87098544b9d3c https://github.com/gentoo/portage/pull/674
What is the rationale, exactly? preserve_old_lib is an awful hack that should not be used in ebuilds.
The idea sprung from irc chat in #gentoo-dev with asturm and radhermit here: > [09:34:15] <juippis> iamben: devmanual says not to revbump :\ > [09:35:18] <WilliamH> You don't need to revbump if you are just tweaking > use flags (which is what python_compat does). > [09:35:49] <WilliamH> I'm not sure why someone is saying you revbump > for that. > [09:36:40] <juippis> because it's cheap and ... I'm guessing pkgcore > can't follow if it's not revbumped > [09:36:58] <WilliamH> That's a bug in pkgcore. > [09:37:08] <WilliamH> emerge -N always picks those up. > [09:37:39] <WilliamH> emerge -NDu @world ;-) > [09:39:36] <mattst88> the requirement to revbump comes from changing > dependencies, which changing PYTHON_COMPAT does > [09:39:44] <mattst88> it's not about the changed USE flag set itself > [09:40:00] <mattst88> but yeah, I think revbumping for PYTHON_COMPAT > changes isn't worth it > [09:40:23] <mattst88> (but you should at least understand the argument > properly) > [09:42:10] <WilliamH> mattst88: Sure, but it is a dependency based on a > use flag setting right? > [09:42:22] <WilliamH> s/dependency/dependency change/ > [09:42:34] <mattst88> yes > [09:42:49] <WilliamH> So I guess it could go both ways... > [09:42:59] <juippis> it does and divides people already :P > [09:43:03] <WilliamH> heh > [09:43:44] <WilliamH> Does this go back to the council decision to turn > off dynamic deps which generated a lot of pushback? > [09:46:22] <WilliamH> Maybe that isn't related... > [10:22:20] <iamben> WilliamH: the most vocal person in favor of revbumping, > says so (in part) because -N/-U are portage-isms, not defined in PMS > [10:22:24] <iamben> as i understand it. > [10:22:57] <iamben> frankly i dont give a rat's ass about any of it > (one way or the other) but i just want to minimize any complaints or > problems for anybody > [10:28:16] <radhermit> the most vocal person also says that like they > are fighting for alternatives when I'm quite sure they still use portage > [10:28:25] <radhermit> it always feels really pedantic to me :P > [10:34:42] <WilliamH> radhermit: heh, I know what you mean. We definitely > have other portage-isms out there too. > [10:34:53] <WilliamH> if has foobar ${FEATURES} > [10:34:59] <WilliamH> in ebuilds for example > [10:35:39] <WilliamH> If we are going to be purists, we should remove > that from ebuilds. :p > [10:36:42] <asturm> of course I had to grep for that > [10:36:45] <radhermit> hmm... > [10:36:51] <asturm> mythtv-31.0-r5.ebuild: has ccache "${FEATURES}" || > myconf+=(--disable-ccache) > [10:38:12] <radhermit> I guess I hadn't considered it yet, but pkgcheck > could flag more of that portage-specific stuff these days with its > pseudo-bash parsing support > [10:38:16] <WilliamH> You'll get false positives, but "git grep > 'has.*FEATURES' > [10:38:25] <radhermit> ... so people could ignore it :P > [10:39:37] <radhermit> at least I rarely run into ebuilds calling portageq > anymore, which entirely breaks merges for me :) > [10:39:58] <radhermit> among other similar things > [10:41:43] <iamben> !meta -v elogviewer > [10:41:44] <willikins> iamben: app-portage/elogviewer; maintainers: > tools-portage > [10:41:44] <willikins> iamben: (tools-portage@gentoo.org) dolsen, idl0r, > zmedico > [10:42:02] <iamben> can i mess with this? new release 1 year ago, also > needs python3_9 added > [10:58:16] <iamben> i guess i was already the one who did the last version > bump too. i think i can do it again. > [11:19:28] <asturm> y'all get a new qtwebengine snapshot today. hope > everyone is looking forward to that > [11:19:32] <radhermit> !bug 692486 > [11:19:32] <willikins> radhermit: https://bugs.gentoo.org/692486 "repoman: > Drop preserve_old_lib check (or change message)"; Portage Development, > Repoman; CONF; arfrever.fta:dev-portage > [11:20:00] <radhermit> ^ whoever maintains repoman these days (no > one?)... that should really be fixed > [11:22:29] <radhermit> and it's along the lines of portage-isms... I'm > just waiting for a newer dev to join base-system and "fix" that when > repoman complains about a system lib, e.g. readline > [11:22:36] <radhermit> :) > [11:27:47] <radhermit> !meta repoman > [11:27:48] <willikins> radhermit: app-portage/repoman; maintainers: > dev-portage > [11:27:53] <radhermit> !meta -v repoman > [11:27:53] <willikins> radhermit: app-portage/repoman; maintainers: > dev-portage > [11:27:53] <willikins> radhermit: (dev-portage@gentoo.org) dolsen, grobian, > robbat2, tommy, vapier, zmedico > [11:28:03] <radhermit> ^ for some additional visiblity > [11:28:20] <asturm> heh, I guess there really are some portageisms > in ebuilds > [11:28:47] <asturm> sam_: good to go with the quazip PR it seems > [11:29:28] <zmedico> radhermit: thanks, I can go ahead and fix that now > [11:32:13] <radhermit> alternatively Gentoo could be more proactive about > canonicalizing features that are treated as near-standard > [11:32:43] <radhermit> i.e. if you're going to break stuff, at least make > it a known standard for those who don't keep up :)
@pms, is it bad for repoman to deprecate preserve_old_lib, given that its removal could lead to breakage in cases where preserve-libs is either not enabled or not supported? (In reply to Zac Medico from comment #5) > Patch posted for review: > > https://archives.gentoo.org/gentoo-portage-dev/message/ > f3434d86197a3c4cf8f87098544b9d3c > https://github.com/gentoo/portage/pull/674
Following the same idea we shouldn't be deprecating anything either because it could lead to breakage. People are supposed to think what they're doing. Slotting is the right solution, not magically preserving libs and abusing slots for the absurd idea of renaming packages.
How do we cope with the ~10% of ebuilds that use subslots, if not with preserve_old_lib? > $ grep -Er '^SLOT=' gentoo/metadata/md5-cache/ | wc -l > 29711 > $ grep -Er '^SLOT=.*/' gentoo/metadata/md5-cache/ | wc -l > 2932 Isn't it confusing to say that it's deprecated, without a plan to remove it?
(In reply to Zac Medico from comment #5) > Patch posted for review: > > https://archives.gentoo.org/gentoo-portage-dev/message/ > f3434d86197a3c4cf8f87098544b9d3c > https://github.com/gentoo/portage/pull/674 I would like to withdraw the above patch, and call upon interested parties to help decide an appropriate course of action or inaction.
(In reply to Zac Medico from comment #10) > How do we cope with the ~10% of ebuilds that use subslots, if not with > preserve_old_lib? > > > $ grep -Er '^SLOT=' gentoo/metadata/md5-cache/ | wc -l > > 29711 > > $ grep -Er '^SLOT=.*/' gentoo/metadata/md5-cache/ | wc -l > > 2932 > > Isn't it confusing to say that it's deprecated, without a plan to remove it? So your idea is to make 10% of overall ebuilds reinvent a cheap hack from Portage in a horrible way?
If everyone agrees that repoman should continue to report that preserve_old_lib is deprecated, then we can just close this bug and leave it at that.
I vaguely remember that there was some use case for preserve-libs.eclass, where relying on Portage's preserve-libs feature could lead to breakage on users' systems.
*** Bug 692486 has been marked as a duplicate of this bug. ***
(In reply to Michał Górny from comment #9) > Slotting is the right solution lib${something}.so.X and lib${something}.so.Y can be placed easily in separate slots, but headers, *.pc files and unversioned lib${something}.so usually cannot. Are you suggesting Gentoo-specific renaming and using another horrible thing like alternatives.eclass? > not magically preserving libs As described in bug #692486, for system packages, preserve_old_lib() is lesser evil than allowing system breakage (for users of other package managers or users of Portage with FEATURES="-preserve-libs"). (In reply to Ulrich Müller from comment #14) > I vaguely remember that there was some use case for preserve-libs.eclass, > where relying on Portage's preserve-libs feature could lead to breakage on > users' systems. preserve_old_lib() already has 'has preserve-libs ${FEATURES} && return 0' to not interfere with Portage's preserve-libs feature.
@mgorny, could you please ack or nack this preserve_old_lib message change? Thanks (In reply to Arfrever Frehtes Taifersar Arahesis from bug 692486 comment #4) > From c692bfe0f809760b76ae416b7f7fb75bf2f7db32 Mon Sep 17 00:00:00 2001 > From: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org> > Date: Sun, 18 Aug 2019 23:23:22 +0000 > Subject: [PATCH] repoman: Change message for preserve_old_lib. > > Bug: https://bugs.gentoo.org/692486 > Signed-off-by: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org> > --- > repoman/cnf/linechecks/linechecks.yaml | 2 +- > repoman/lib/repoman/modules/linechecks/deprecated/deprecated.py | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/repoman/cnf/linechecks/linechecks.yaml b/repoman/cnf/linechecks/linechecks.yaml > index 2182b467a..55c163f7b 100644 > --- a/repoman/cnf/linechecks/linechecks.yaml > +++ b/repoman/cnf/linechecks/linechecks.yaml > @@ -25,7 +25,7 @@ errors: > DEPRECATED_BINDNOW_FLAGS: 'Deprecated bindnow-flags call' > EAPI_DEFINED_AFTER_INHERIT: 'EAPI defined after inherit' > NO_AS_NEEDED: 'Upstream asneeded linking bug (no-as-needed)' > - PRESERVE_OLD_LIB: 'Ebuild calls deprecated preserve_old_lib' > + PRESERVE_OLD_LIB: 'Ebuild calls preserve_old_lib function reserved for libraries used by system packages' > BUILT_WITH_USE: 'built_with_use' > NO_OFFSET_WITH_HELPERS: 'Helper function is used with D, ROOT, ED, EROOT or EPREFIX' > USEQ_ERROR: 'Ebuild calls deprecated useq function' > diff --git a/repoman/lib/repoman/modules/linechecks/deprecated/deprecated.py b/repoman/lib/repoman/modules/linechecks/deprecated/deprecated.py > index d1a590f1d..48fee6ce2 100644 > --- a/repoman/lib/repoman/modules/linechecks/deprecated/deprecated.py > +++ b/repoman/lib/repoman/modules/linechecks/deprecated/deprecated.py > @@ -19,7 +19,7 @@ class DeprecatedHasq(LineCheck): > > > class PreserveOldLib(LineCheck): > - """Check for calls to the deprecated preserve_old_lib function.""" > + """Check for calls to the preserve_old_lib function reserved for libraries used by system packages.""" > repoman_check_name = 'ebuild.minorsyn' > re = re.compile(r'.*preserve_old_lib') > error = 'PRESERVE_OLD_LIB' > -- > 2.30.0
(In reply to Zac Medico from comment #17) > @mgorny, could you please ack or nack this preserve_old_lib message change? > Thanks > > (In reply to Arfrever Frehtes Taifersar Arahesis from bug 692486 comment #4) > > From c692bfe0f809760b76ae416b7f7fb75bf2f7db32 Mon Sep 17 00:00:00 2001 > > From: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org> > > Date: Sun, 18 Aug 2019 23:23:22 +0000 > > Subject: [PATCH] repoman: Change message for preserve_old_lib. > > > > Bug: https://bugs.gentoo.org/692486 > > Signed-off-by: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org> > > --- > > repoman/cnf/linechecks/linechecks.yaml | 2 +- > > repoman/lib/repoman/modules/linechecks/deprecated/deprecated.py | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/repoman/cnf/linechecks/linechecks.yaml b/repoman/cnf/linechecks/linechecks.yaml > > index 2182b467a..55c163f7b 100644 > > --- a/repoman/cnf/linechecks/linechecks.yaml > > +++ b/repoman/cnf/linechecks/linechecks.yaml > > @@ -25,7 +25,7 @@ errors: > > DEPRECATED_BINDNOW_FLAGS: 'Deprecated bindnow-flags call' > > EAPI_DEFINED_AFTER_INHERIT: 'EAPI defined after inherit' > > NO_AS_NEEDED: 'Upstream asneeded linking bug (no-as-needed)' > > - PRESERVE_OLD_LIB: 'Ebuild calls deprecated preserve_old_lib' > > + PRESERVE_OLD_LIB: 'Ebuild calls preserve_old_lib function reserved for libraries used by system packages' How about skipping 'libraries used by'? It doesn't seem to change the meaning (i.e. libraries used by system packages are system packages too).
(In reply to Michał Górny from comment #18) > How about skipping 'libraries used by'? It doesn't seem to change the > meaning (i.e. libraries used by system packages are system packages too). Yes, that's true. Thanks for your feedback. We now refer to it as "preserve_old_lib function reserved for system packages": https://gitweb.gentoo.org/proj/portage.git/commit/?id=d4bd6045a50c4e662e36c2ad247c6c13d6f3e534
