Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI
On Sat, 28 Sep 2013, heroxbd wrote: I am revisiting this topic based on previous discussions[1,2,3]. There seems to be a constant need for toolchain with a new EAPI. The only block is how can we upgrade from an ancient system?, don't bump or the upgrade path will be break. Let's figure out a solid upgrade path consciously, with a test farm of ancient systems, and then bump the EAPI of toolchain. The upgrade path is not at all what is blocking this. In its 20130409 meeting, the council has (unanimously) decided: EAPIs 0 to 2 are no longer required for the upgrade path of users' systems. The reason why toolchain packages are still at EAPI 0 was explained in this posting: http://thread.gmane.org/gmane.linux.gentoo.project/2369/focus=2377 AFAICS, changing that is entirely the task of the toolchain team. Ulrich
[gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
Matt Turner matts...@gentoo.org wrote: || ( =dev-lang/perl-5.14 virtual/perl-Term-ANSIColor ) and possibly change this if perl-5.20 does no longer contain perl-Term-ANSIColor. Isn't that exactly what the virtual should do? One can discuss what it *should* do, but it is certainly not what happens, because the virtual exists in different versions: If you only depend on virtual/perl-Term-ANSIColor, it would currently install perl-core/Term-ANSIColor-4.20 *in addition* to the one provided by perl-5.14/5.16 (which is Term-ANSIColor-4.02 or -3.0.0, respectively). Note that it would be stupid to depend on e.g. =virtual/perl-Term-ANSIColor-4.02 for several reason: 1. The virtual does not even exist :) 2. It would collide with ebuilds depending on other versions. 3. This version is only reasonable if perl-5.16 is the perl version which the user has installed.
[gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
Kent Fredric kentfred...@gmail.com wrote: you'll still need logic like || ( dev-lang/perl[perl_module_Term_ANSIColor(-)] perl-core/Term-ANSIColor ) to just deal with the reality of what upstream are asking for. My point is that the perl ebuild need not necessarily follow upstream: It follows what the perl *ebuild* provides. If upstream decides to remove a package, you can just pull it from the ebuild (with PDEPEND, I agree) nevertheless. If such a list of USE flags existed, it would be a very strong recommendation that they *ALL* be turned on. Yes, this is why I said manually disabling is comparable with setting USE=minimal: for most users not recommended unless you really have the necessity to build a minimal system for some reason. So I would not care too much about occassional unnecessary recompilation of perl itself only for the small numbers of users having such a necessity. And pulling in perl-core/Whatever by doing =dev-lang/perl[perl_module_whatever] is just a nastier form of virtual/perl-Whatever, with the limitation that you're completely destroying any version support. If you need version support you still can depend on perl-core or virtual/* but currently there is no way to explicitly prefer the perl-provided version in the dependency (unless you code it manually). Thats not really the issue, the issue is that because the modules *ARE *deemed dual life by upstream, that is, it is expected that end users can depend on a specific version of a module that exists in both perl itself, and as a standalone, that end users *may* depend on such things and expect that to work. Yes, he may depend on the explicit perl-core/* with version (and perhaps also some virtual/* where it is likely that such an explicit version is provided by perl itself - probably only very few): As mentioned above, this involves only a relatively small number of virtuals. Here is how I got the list: eix --print-all-depends | sed 's///g' \ grep -o '[^ ]*virtual/perl-[^ ]*-[0-9][^ ]*' |sort -u I get 566 for me. different *minimal versions* but much less (IIRC 62) packages which is already now lower than the number of virtual/perl-*. Moreover, many of the minimal versions are probably meanwhile redundant (since the highest version is stable anyway and often already provided by current stable perl). Since most packages occur only once or twice, I guess that if the redundancy is eliminated you end up with only 10-20 for which a virtual might really make sense (or, alternatively, for which you must directly depend on perl-core/*, since the probability to just have the correct version in perl is rather low anyway). And note, you're showing the dependencies, not the dependants. This is the point, because only this is what is interesting: You do not need a virtual with version number if absolutely nothing is using it. If you remove the unique criteria, you get a lovely 20260 lines of output! This number has no meaning. Moreover, if you should decide to change the way how modules depend, this is a question of writing a single perl-script ;) which changes the style in all ebuilds. I can gladly provide such a script if you want. || ( =dev-lang/perl-5.14 virtual/perl-Term-ANSIColor ) That is plain wrong imo. You're prematurely optimising the dependency. The alternative is to pull in a duplicated installation which is completely superfluous, since it is already installed by most perl versions, There is no guarantee any future version of Perl will contain it. That's why it is necessary to manually update the dependency - a lot more work than to depend on dev-lang/perl[Term-ANSIColor] and only edit a future perl ebuild to pull in the package. The virtuals job is to invoke dependency on dev-lang/perl as much as possible, and default to perl-core/* when dev-lang/perl does not provide the version matched on the virtual. In this example (one of many) the version plays no role for the dependency, but nevertheless the virtual/... implementation will pull in an unnecessary package. I'd also sooner consider attempting to eliminate the need for virtuals by unilaterally depending on perl-core/* , and vivifying perl-core/ from dev-lang/perl sources as needed. This breaks proper support for building/using binary packages for perl-core/* since the installed files will depend on which packages are installed at build-time.
[gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
Kent Fredric kentfred...@gmail.com wrote:
I mean, the reason virtuals suck is predominantly the fact we have to
update the conditionals to accurately reflect the version on the virtual
Concerning the eclass idea which was already mentioned and
which is perhaps even better than my suggeestion from the
other posting, since it avoids some of the disadvantages:
by having an eclass that translates a special variable, say,
PERL_MODULE_COREDEPS=Term::ANSIColor@3.2 or something
I would keep it simple like
RDEPEND=$(perl-dep Term-ANSIColor)
$(perl-dep =Module-Load-0.240.0)
which would then translate into something like
RDEPEND=( || ( ( =perl-5.12 =perl-5.18.1 ) perl-core/Term-ANSIColor )
|| ( =perl-5.18 =perl-core/Module-Load-0.240.0 )
(or || ( ( perl-5.12* perl-5.14* ...
|| ( perl-5.18* ...) -
subject to further discussion)
Of course, perl-dep might also loop over its arguments...
Transfer of current ebuilds into the new format would be trivial:
s{(\S*)virtual/perl-(\S*)}{\$\(perl-dep \$1$2\\)}g
(and adding the inherit if at least one match occured).
something I really want to avoid, mostly, because the massive amount of
moving parts required to implement such a feature.
If the eclass is written generically you only have to fill in
one list for each perl-version (further simplifications of the data
format are thinkable) containg the provided packages e.g. in
the form category/package-version
If there is interest, I might volunteer to provide a first form
of such an eclass (though I can make no promises in the moment).
Re: [gentoo-dev] [RFC] Policy for migrating library consumers to subslots
On Thu, Sep 26, 2013 at 7:39 PM, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/09/13 11:24 AM, Davide Pesavento wrote: On Thu, Sep 26, 2013 at 4:04 PM, Kent Fredric kentfred...@gmail.com wrote: On 26 September 2013 19:53, Michał Górny mgo...@gentoo.org wrote: How do we handle packages which install multiple libraries? I'm afraid forcing such a policy and/or hurrying developers to adapt will only cause more of poppler-like issues to occur. Can you give a an example package which: - installs multiple libraries - has an ABI that may change for only one of those libraries - it is sane / plausible to expect one downstream dependent *not* to forcibly rebuild as a result of a chane in one of those libaries - it is sane / plausible to expect a different downstream to forcibly rebuild as a result of changes in one of those libraries dev-python/PyQt4 Each module is a separate library, and each has its own ABI that can change independently from the others. Downstream projects that rely only on PyQt4's python API are not affected by ABI changes, but those (very few) that link against one or more modules (e.g. kde-base/pykde4 I think) must be rebuilt. To better round off this example, I assume that the API itself also changes as a whole, and slot-operators are the ideal means to force rebuilds on all rdeps when that occurrs? Not sure what you mean by the API also changes as a whole. The ABI can change without the API changing, if that's what you're asking, but I'm sure you already know that... Otherwise, I don't see why this example couldn't be satisfied by bumping subslot whenever any sub-ABI changes and only using slot-operators in *DEPEND atoms on those very few packages that link to the modules. You'd force unnecessary rebuilds for reverse deps not using the library that changed ABI, just like the poppler case. And there's an additional problem here: from what I've seen, most people blindly add subslot operators in *DEPEND when they see that the dep has gained a subslot, even when it's not needed at all (e.g. python-only packages in the PyQt4 case). Thanks, Davide
Re: [gentoo-dev] [RFC] Policy for migrating library consumers to subslots
On Fri, Sep 27, 2013 at 4:44 PM, Michał Górny mgo...@gentoo.org wrote:
Dnia 2013-09-26, o godz. 17:24:49
Davide Pesavento p...@gentoo.org napisał(a):
On Thu, Sep 26, 2013 at 4:04 PM, Kent Fredric kentfred...@gmail.com wrote:
On 26 September 2013 19:53, Michał Górny mgo...@gentoo.org wrote:
How do we handle packages which install multiple libraries? I'm afraid
forcing such a policy and/or hurrying developers to adapt will only
cause more of poppler-like issues to occur.
Can you give a an example package which:
- installs multiple libraries
- has an ABI that may change for only one of those libraries
- it is sane / plausible to expect one downstream dependent *not* to
forcibly rebuild as a result of a chane in one of those libaries
- it is sane / plausible to expect a different downstream to forcibly
rebuild as a result of changes in one of those libraries
dev-python/PyQt4
Each module is a separate library, and each has its own ABI that can
change independently from the others. Downstream projects that rely
only on PyQt4's python API are not affected by ABI changes, but those
(very few) that link against one or more modules (e.g. kde-base/pykde4
I think) must be rebuilt.
How often does ABI of pyqt4 libraries change in such a way that rebuild
of pykde4 is not required?
Practically never (see below).
Looking at the dep:
=dev-python/PyQt4-4.9.5[${PYTHON_USEDEP},dbus,declarative,script(+),sql,svg,webkit,X]
I'd think it's fairly rare when only the libraries not listed above
change ABI without any of the remaining ones changing it.
Actually, most PyQt4 libraries never changed their ABIs since the
initial 4.0 release, so yes, it's fairly rare :)
That's also one of the reasons why I never bothered to add a subslot to PyQt4.
Thanks,
Davide
Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/28/2013 03:00 AM, Ulrich Mueller wrote: On Sat, 28 Sep 2013, heroxbd wrote: I am revisiting this topic based on previous discussions[1,2,3]. There seems to be a constant need for toolchain with a new EAPI. The only block is how can we upgrade from an ancient system?, don't bump or the upgrade path will be break. Let's figure out a solid upgrade path consciously, with a test farm of ancient systems, and then bump the EAPI of toolchain. The upgrade path is not at all what is blocking this. In its 20130409 meeting, the council has (unanimously) decided: EAPIs 0 to 2 are no longer required for the upgrade path of users' systems. The reason why toolchain packages are still at EAPI 0 was explained in this posting: http://thread.gmane.org/gmane.linux.gentoo.project/2369/focus=2377 AFAICS, changing that is entirely the task of the toolchain team. Yes, it is entirely the task of the toolchain team, and looks like heroxbd joined the toolchain team and would like to push the rest of his team for this update. Something I greatly thank him for. I don't think any dev wants to (or really could) force toolchain to update individually, however, if motivated people want to join the team and help, his question appeared to be will it be permitted to be updated. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSRwnhAAoJEKXdFCfdEflKVycP/RrDx0riRF9HO8yjMlPxPRmX Fm4xl+KdGNiKIxHDKVKGehyHDGyEVxUq8ZtrNqkQurtgibhtI2eErOjWYVHsV2Yj A2lW8JubwvYn14Qk0Pem9jg5cGTbo1mEA4UGG2XMWYzyGJkXi/m+alJYTQfZpbGk VKwll6wAMpPpVoV/xAA/mHX5AJrALQrP9/0xqOtvcSSvJTZvu4rpLFPWRlUf6Q6C Z+0grxc3x6Nq6Ryn6f39KLRYgXv6AEwx9ieajKu7ES+rBbTWsJCHtPD+H3zZbJI8 g+/2GPMgDmQ9tMQwuBwPdylUzGhPwd8Gmd6546mnBPOlZZNsJxBc/Cqt1paMyaPy sZp2igbXR5B9ha6Tg5bW7j6WDKqr9QZAslGYrXJa25wwmvcBQV+EsJrmmpQbDCdi todWjippnmJATDHVsHR1tW11/iO0t6UUKI8jLZm7HCaGXRptILWfICYYXAM19ntq 9DWpA4BIpQzZx0s3cQZ1eIB3lHxPL387UWitAI9zW23Q0VYfddQgbLKbAo76GkR7 3ta6wjvIJ2vPBgxvv5Eo/hfKMUtxxyGeA/Jp6+zRMKPxcsqBocQXMs7pdmTON3Mb ddDLJ88tPc9QenHzE4PwCiTjSPDCSQRzrhmzt1iQEsIitVXDnL5kXGt38MfxT9We 7p2PfdN8P4VekqKIcEVT =ROKo -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Policy for migrating library consumers to subslots
On 2013-09-28, at 9:43 AM, Davide Pesavento p...@gentoo.org wrote:
On Fri, Sep 27, 2013 at 4:44 PM, Michał Górny mgo...@gentoo.org wrote:
Dnia 2013-09-26, o godz. 17:24:49
Davide Pesavento p...@gentoo.org napisał(a):
On Thu, Sep 26, 2013 at 4:04 PM, Kent Fredric kentfred...@gmail.com wrote:
On 26 September 2013 19:53, Michał Górny mgo...@gentoo.org wrote:
How do we handle packages which install multiple libraries? I'm afraid
forcing such a policy and/or hurrying developers to adapt will only
cause more of poppler-like issues to occur.
Can you give a an example package which:
- installs multiple libraries
- has an ABI that may change for only one of those libraries
- it is sane / plausible to expect one downstream dependent *not* to
forcibly rebuild as a result of a chane in one of those libaries
- it is sane / plausible to expect a different downstream to forcibly
rebuild as a result of changes in one of those libraries
dev-python/PyQt4
Each module is a separate library, and each has its own ABI that can
change independently from the others. Downstream projects that rely
only on PyQt4's python API are not affected by ABI changes, but those
(very few) that link against one or more modules (e.g. kde-base/pykde4
I think) must be rebuilt.
How often does ABI of pyqt4 libraries change in such a way that rebuild
of pykde4 is not required?
Practically never (see below).
Looking at the dep:
=dev-python/PyQt4-4.9.5[${PYTHON_USEDEP},dbus,declarative,script(+),sql,svg,webkit,X]
I'd think it's fairly rare when only the libraries not listed above
change ABI without any of the remaining ones changing it.
Actually, most PyQt4 libraries never changed their ABIs since the
initial 4.0 release, so yes, it's fairly rare :)
That's also one of the reasons why I never bothered to add a subslot to PyQt4.
Thanks,
Davide
it is very important to note that slot operators should be used even when the
atom is unlikely to ever bump ABI or SONAME. it is the rare big update that
breaks everything -- think the expat update fiasco from a few years back.
Re: [gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
On 28 September 2013 22:31, Martin Vaeth va...@mathematik.uni-wuerzburg.dewrote: Note that it would be stupid to depend on e.g. =virtual/perl-Term-ANSIColor-4.02 for several reason: 1. The virtual does not even exist :) Nope, it does. Its just called =virtual/perl-Term-ANSIColor-4.20.0 , because upstreams versioning semantics are grossly different to gentoos, so we translate upstreams floating point versions to multipart versions so that version cross-dependency semantics stay the same. 2. It would collide with ebuilds depending on other versions. Nope, it would only collide in the case other ebuilds depended on a specific version, or blocked a specific version. This is seen as a feature, because of foo needs = y-nnn you don't want to have to logically tract that fact in every other package that needs y 3. This version is only reasonable if perl-5.16 is the perl version which the user has installed And when perl 5.18 hits tree, if you want exactly 4.20 or larger, you'll need to change your dependency string in your package to incorporate this fact, instead of saying =virtual/perl-Term-ANSIColor-4.20.0 you'll have to do || ( perl-5.18 etc etc ) , which is pushing the dependency management of all the virtuals into the pacakges that are requring them. Virtuals are much more convenient here, because if we need to change the provider of a single version, we change it in *one* place, instead of having to modify every ebuild in tree that needed it. ( Actually, thats a bug still, because corelist -a says 4.20.0 should be available in 5.18, but the virtual for 4.20.0 doesn't yet have perl-5.18 listed as a provider, though I'm glad it can be fixed once, there, instead of having to fix it in every package that depended on 4.20.0 prior to the arrival of 5.18 in tree ) -- Kent
Re: [gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
On 28 September 2013 22:46, Martin Vaeth va...@mathematik.uni-wuerzburg.dewrote: Kent Fredric kentfred...@gmail.com wrote: you'll still need logic like || ( dev-lang/perl[perl_module_Term_ANSIColor(-)] perl-core/Term-ANSIColor ) to just deal with the reality of what upstream are asking for. My point is that the perl ebuild need not necessarily follow upstream: It follows what the perl *ebuild* provides. If upstream decides to remove a package, you can just pull it from the ebuild (with PDEPEND, I agree) nevertheless. So are you basically suggesting that for dual life modules, we simply ignore that they're dual-lifeable, and then when upstream splits a package from core so that its no longer dual life, that we simply ignore that too, and fake it still being core for the forseeable future? If such a list of USE flags existed, it would be a very strong recommendation that they *ALL* be turned on. Yes, this is why I said manually disabling is comparable with setting USE=minimal: for most users not recommended unless you really have the necessity to build a minimal system for some reason. So I would not care too much about occassional unnecessary recompilation of perl itself only for the small numbers of users having such a necessity. IMO, really, the uses would be forced enabled for all users, because they should never be disabled. If they're part of the Perl built itself, they should get installed. Period. Then by forcing them on all the time, you can use them how you were initially suggesting, as a way to track interdependencies between versions of perl ( ie: When perl itself stops being able to provide something, the USE flag goes away ... but thats messy as hell, and an abuse of the entire purpose of USE flags, to control features, not to simply track properties of a package for the purpose of cross dependencies ) For that, a slot-dict approach is far more sane. And pulling in perl-core/Whatever by doing =dev-lang/perl[perl_module_whatever] is just a nastier form of virtual/perl-Whatever, with the limitation that you're completely destroying any version support. If you need version support you still can depend on perl-core or virtual/* but currently there is no way to explicitly prefer the perl-provided version in the dependency (unless you code it manually). But why would you depend on the perl-provided version , that mentality is nowhere upstream, and nowhere downstream. Are you saying that, if something is provided by perl core, that we must never update to a cpan version? You realise thats breaking how upstream thinks toolchains work right? Because even CPAN and friends like that will upgrade things in core to their cpan versions where possible. There is *no* way for upstream to declare I want whatever version of X is in your current perl, they can only state I want X or fail to state they want X, and assume toolchain does the right thing. Even then, that will result in tools using more recent versions of things from CPAN. Thats not really the issue, the issue is that because the modules *ARE *deemed dual life by upstream, that is, it is expected that end users can depend on a specific version of a module that exists in both perl itself, and as a standalone, that end users *may* depend on such things and expect that to work. Yes, he may depend on the explicit perl-core/* with version (and perhaps also some virtual/* where it is likely that such an explicit version is provided by perl itself - probably only very few): But that raises a problem, because some versions that end users may depend on are *NOT* available as perl-core/* , they are only available in a specific incarnation of Perl. Or sometimes, a version will appear on CPAN, and people will start depending on it ( requiring you to invoke a perl-core/* dependency ), and later, that version will be shipped in perl itself, resulting in the need to retroactively modify every ebuild that depended on perl-core/* of those versions to use the perl one instead. Because otherwise, you'll have end users complaining they have to install perl-core/Term-ANSIColor-4.20.0 when they're using 5.18.0, which comes with that version anyway. And note, you're showing the dependencies, not the dependants. This is the point, because only this is what is interesting: You do not need a virtual with version number if absolutely nothing is using it. If you remove the unique criteria, you get a lovely 20260 lines of output! This number has no meaning. Moreover, if you should decide to change the way how modules depend, this is a question of writing a single perl-script ;) which changes the style in all ebuilds. I can gladly provide such a script if you want. You're missing a very important point: Every single line of output without the uniq constraint is a package depending on a virtual. The virtual is managing the need to have a conditional dependency based on the version of
Re: [gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
On Sun, 29 Sep 2013 08:47:52 +1300 Kent Fredric kentfred...@gmail.com wrote: For that, a slot-dict approach is far more sane. The only reason anyone can make that claim is that no-one really knows what slot dictionaries are or how they'd work in practice. Until there's a rough description of how they work and a prototype implementation, subslot dictionaries is like magic beans. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
On 28 September 2013 23:36, Martin Vaeth
va...@mathematik.uni-wuerzburg.dewrote:
Concerning the eclass idea which was already mentioned and
which is perhaps even better than my suggeestion from the
other posting, since it avoids some of the disadvantages:
by having an eclass that translates a special variable, say,
PERL_MODULE_COREDEPS=Term::ANSIColor@3.2 or something
I would keep it simple like
RDEPEND=$(perl-dep Term-ANSIColor)
$(perl-dep =Module-Load-0.240.0)
which would then translate into something like
RDEPEND=( || ( ( =perl-5.12 =perl-5.18.1 ) perl-core/Term-ANSIColor )
|| ( =perl-5.18 =perl-core/Module-Load-0.240.0 )
(or || ( ( perl-5.12* perl-5.14* ...
|| ( perl-5.18* ...) -
subject to further discussion)
The most annoying thing about that would be the implementation details.
The reason virtuals are such a nightmare for perl is really the way they're
oriented.
Every perl we release, we have to manually update something, somewhere
in a location *other* than the perl ebuild itself.
Which means that instead of simply modifying perl's .ebuild, and walking
the contents of module::corelist and saying This version provides X
version Y, one must instead have a way to reorient that data from the
perspective of dependencies.
That is, we must reorganize all the code in question in terms of X version
Y, as a list of things that provide that X version Y.
And thats the most no-trivial part of the equation.
The best solution I presently have for this problem, would be to have a
PROVIDES-${PV}.json file in every package under files/
That file would contain simply a list of provisions ( a literal string )
with a version of that provision.
And then we could mangle that data as an aggregate by iterating the whole
portage tree, collecting such files, and using them to provide the inverse
relationmap of X verison Y is provided by Z version N, which could be
used by a suitable eclass.
Thats really as clean, and logical, as I can imagine making it. Just its
investment intensive, and investment intensive in ways that would be better
supported as a native portage feature.
--
Kent
Re: [gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
On 29 September 2013 08:51, Ciaran McCreesh ciaran.mccre...@googlemail.comwrote: The only reason anyone can make that claim is that no-one really knows what slot dictionaries are or how they'd work in practice. Until there's a rough description of how they work and a prototype implementation, subslot dictionaries is like magic beans. Indeed, but I can basically say without looking at such a competing strategy, that as insane as the prototype may be in practise, it would be grossly preferable to have that mechanic as an internal dependency control mechanism, instead of something that more-or-less amounts to enumerating the contents of a large package ( perl ), and essentially converting all the file names in that package to a distinct USE_EXPAND useflag, and then basically making them *ALL* on by default and having to tell users Don't turn them off unless you're smart/stupid!. That'd be like shooting somebody in the head as a cure for cancer. -- Kent
Re: [gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
On 29 September 2013 09:14, Martin Vaeth va...@mathematik.uni-wuerzburg.dewrote: this dependency will install for a user with unstable keywords That, in itself, indicates the user is usually OK with new versions of things ;) corelist -a says virtual/perl-Digest-MD5-2.520.0 should || ( perl v5.18 ) Though that virtual is already stable, and as a result, will result in the installation of that version of Digest::MD5 on perl versions 5.17 2.530.0 won't be in perl till 5.19+ One other reason you might want to consider that its *good* that we upgrade things from perl to versions in perl-core/*. CVEs. If a security hole is exposed in a version of something that is shipped with perl, we can simply adjust the virtual and get it to pull in a newer version via perl-core/* Here, the unnecessary dependency could in fact be nessecary to avoid a security hole in an older version that may be shipped with perl. And in such a case, its good that installing foo, that depends on virtual/perl-SOMETHINGBROKEN gets you a version more recent than in perl itself. -- Kent
[gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
Kent Fredric kentfred...@gmail.com wrote: So are you basically suggesting that for dual life modules, we simply ignore that they're dual-lifeable, and then when upstream splits a package from core so that its no longer dual life, that we simply ignore that too, and fake it still being core for the forseeable future? Yes, this is the idea. (Although I must admit that meanwhile I prefer the ebuild idea). IMO, really, the uses would be forced enabled for all users, because they should never be disabled. If they're part of the Perl built itself, they should get installed. Period. Exactly: Those which are part of the Perl built itself would not have a useflag at all. Only for those which are *not* in part of the current perl built you would have a useflag. For instance, USE=Time-Piece would not occur in the perl-5.10* ebuilds but in all other perl ebuilds in the form PDEPEND=Time-Piece? ( perl-core/Time-Piece ) Packages needing Time-Piece would then just RDEPEND=dev-lang/perl[Time-Piece(+)] and would thus implicitly get the correct dependency. Once the translation is done, the only place where maintenance is needed are the perl-ebuilds. But why would you depend on the perl-provided version Many packages only need the basic functionality of a library, not a particular version. The problem is that something like RDEPEND=virtual/perl-... implicitly depends on a particular version, namely the highest one which is currently stable/unstable for your architecture instead of the one which avoids unnecessary installation. Are you saying that, if something is provided by perl core, that we must never update to a cpan version? If the user explicitly requires a particular package or if a package explicitly depends on a certain minimal version, the upgrade will be automatic. However, if there is no need (dependency or explicit user request) for a particular version, the installed version should be sufficient. You realise thats breaking how upstream thinks toolchains work right? Upstream always thinks that you have to use the most current unstable version of everything. This is not only true for perl but also for every other bigger project (texlive or many others come to mind). It is the distribution's task to give a more stable user experience. You're missing a very important point: Every single line of output without the uniq constraint is a package depending on a virtual. This is not the case, but this need not be discussed here; we agree that the number of *packages* depending on virtual versions is large. The virtual is managing the need to have a conditional dependency based on the version of perl installed. You would need to ,without virtuals, modify *EVERY* ebuild containg a dependency on a virtual, to contain the respective conditional dependency enshrined in the virtual. No. You just keep those few virtuals for which the packages explicitly depend on the version. The remaining ones - for which the version plays no role - are replaced *once* by the corresponding USE-dependency. (However, as said above, I meanwhile prefer the eclass idea; with the eclass you could treat both cases - those depending on a particular version and those depending only on *some* version - in the same way and even omit all virtuals.) Not sure about you, but the idea of modifying 20,000 lines of code instead of 1, is something I don't look on fondly. Both solutions would require only *once* to modify the dependencies. After the transfer is done, you only have to modify 1 line || ( =dev-lang/perl-5.14 virtual/perl-Term-ANSIColor ) That is plain wrong imo. You're prematurely optimising the dependency. The alternative is to pull in a duplicated installation which is completely superfluous, since it is already installed by most perl versions, You're not though. Thats the point. Virtuals are doing exactly that. They're just doing it in the virtual instead of your ebuild. Only if there would be only *one* version of the corresponding virtual. With *more* virtual versions as it is currently, it is rather likely that an unneeded version of perl-core/Term-ANSIColor is pulled it. If you are installing virtual Y version X, if you are on a version of Perl that contains Y version X, the virtual avoids the need to install the respective perl-core/X. But if I am just installing virtual Y, version does not matter, I will likely get virtual Y, versions X+Z although version X is already there and thus version Z would not be needed. If you don't like that packages get updated, and pull newer-that-core versions of things, there's nothing to stop you grepping virtual/perl-*, and masking versions that don't match an =your current version of perl. This is a lazy excuse: Instead of producing proper dependencies you are shifting the work to the user. In fact, I did this work in the beginning, but not only is this a lot of work for every perl upgrade (which is not so trivial to script), you also
[gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
Kent Fredric kentfred...@gmail.com wrote:
--001a11336248343a2604e7770011
Content-Type: text/plain; charset=UTF-8
On 28 September 2013 23:36, Martin Vaeth
va...@mathematik.uni-wuerzburg.dewrote:
Concerning the eclass idea which was already mentioned and
which is perhaps even better than my suggeestion from the
other posting, since it avoids some of the disadvantages:
by having an eclass that translates a special variable, say,
PERL_MODULE_COREDEPS=Term::ANSIColor@3.2 or something
I would keep it simple like
RDEPEND=$(perl-dep Term-ANSIColor)
$(perl-dep =Module-Load-0.240.0)
It would have been wiser to suggest here the syntax
perl-core/Term-ANSIColor and perl-core/Module-Load-0.240.0,
respectively so that the category need not be fixed to
perl-core.
which would then translate into something like
RDEPEND=( || ( ( =perl-5.12 =perl-5.18.1 ) perl-core/Term-ANSIColor )
|| ( =perl-5.18 =perl-core/Module-Load-0.240.0 )
(or || ( ( perl-5.12* perl-5.14* ...
|| ( perl-5.18* ...) -
subject to further discussion)
The most annoying thing about that would be the implementation details.
Why? One of use probably misunderstand something:
Every perl we release, we have to manually update something, somewhere
in a location *other* than the perl ebuild itself.
If you decide to use the eclass, then with each perl release
you would have to update the data in the eclass - namely the LIST of
provided packages for that new version. Something like
LIST_perl5.18=(
perl-core/Term-ANSIColor-4.20
perl-core/...-...
dev-perl/...-...
!perl-core/X-Y
!!perl-core/X-Y
)
LIST_perl5.16=(
)
...
AVAILABLE_PERLS=5.18 5.16 ...
where the special symbols ! means that version perl-core/X-Y is
not available in the tree and !! means that perl-core/X is not
available in the tree (in no version).
These LISTs are all which you have to update for new perl versions.
The rest should be handled by the logic of the eclass, and I do not
see why this should be hard to do:
1.
If perl-dep is called with the argument
=category/package-version,
category/package-version,
=category/package-version,
category/package-version,
=category/package-version, or
~category/package-version,
the function just output into || ( ... ) all perl versions which provide
a matching package according to LIST, followed by the passed argument
(the latter is skipped, if masked by ! or !! according to one LIST).
In case of = or in addition the blocker
!category/package-version or !=category/package-version
is output (unless masked by ! or !!).
2.
If perl-dep is called with the argument
catogory/package
(without a version) the function just adds into || ( ... ) all
perl versions which provide the package and in addition ends with
the passed argument (unless masked by !!).
Implementation of that function is rather simple once you have
a version comparison function (I do not remember in the moment
whether this is already available in some eclass or will be
only available the next EAPI).
Of course, the output could be optimized by omitting the || ( ) symbols
if there is only one match etc.
Which means that instead of simply modifying perl's .ebuild, and walking
the contents of module::corelist and saying This version provides X
version Y, one must instead have a way to reorient that data from the
perspective of dependencies.
Why? You update the eclasses LIST variables in one place when a new
version of perl comes out. All functions needing a perl
package use the perl-dep function (which means a one-shot change for
all packages needing a perl package; for packages in the
tree this can be done by the script I mentioned).
The best solution I presently have for this problem, would be to have
a PROVIDES-${PV}.json file in every package under files/
Not under files but in the eclass, and the rest of the
work is done by the perl-dep function.
[gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
Kent Fredric kentfred...@gmail.com wrote: this dependency will install for a user with unstable keywords That, in itself, indicates the user is usually OK with new versions of things ;) You are intentionally confusing new version (AKA upgrade) with _additional_ installation of a package, just because that package contains a newer version. If you explicitly installed that package, an upgrade of course is desired, but *hard depending* on a package just because it provides a newer version of a bundled package is more than questionable: Would you think that it is correct if e.g. a multimedia package which *forcibly* has bundled ffmpeg should in addition *forcibly* depend on the system ffmpeg library (for no other reason than it is bundled anyway)? According to your definition of always guarantee to install new version this would have to be the case. I agree that no solution is completely satisfactory: The most correct solution might be to unbundle the library - which for perl would mean to *not* install the provided modules but put all of them in perl-core. But as often, unbundling is here a *very* hard job (how to solve the chicken-and-egg problem of installing perl packages without having packages available for installation) and probably manpower is missing to do this for every perl version... But in fact, this solution would allow complete elimination of all artificial workarounds by virtuals, eclasses or USE-flags and circumvent the problem of duplicate installation of packages completely.
Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI
Rick \Zero_Chaos\ Farina zeroch...@gentoo.org writes: On 09/28/2013 03:00 AM, Ulrich Mueller wrote: On Sat, 28 Sep 2013, heroxbd wrote: I am revisiting this topic based on previous discussions[1,2,3]. There seems to be a constant need for toolchain with a new EAPI. The only block is how can we upgrade from an ancient system?, don't bump or the upgrade path will be break. Let's figure out a solid upgrade path consciously, with a test farm of ancient systems, and then bump the EAPI of toolchain. The upgrade path is not at all what is blocking this. In its 20130409 meeting, the council has (unanimously) decided: EAPIs 0 to 2 are no longer required for the upgrade path of users' systems. The reason why toolchain packages are still at EAPI 0 was explained in this posting: http://thread.gmane.org/gmane.linux.gentoo.project/2369/focus=2377 AFAICS, changing that is entirely the task of the toolchain team. Thank you for the clarification, Ulrich. Yes, it is entirely the task of the toolchain team, and looks like heroxbd joined the toolchain team and would like to push the rest of his team for this update. Something I greatly thank him for. I don't think any dev wants to (or really could) force toolchain to update individually, however, if motivated people want to join the team and help, his question appeared to be will it be permitted to be updated. Can't agree with you more. It's just a starting point, though. I still don't have a clear plan yet. After reading carefully the thread Ulrich pointed out, it seems that refactoring ebuild/eclass is invevitable, which calls for an overlay to carry it on. Benda
Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/28/2013 10:12 PM, hero...@gentoo.org wrote: Rick \Zero_Chaos\ Farina zeroch...@gentoo.org writes: On 09/28/2013 03:00 AM, Ulrich Mueller wrote: On Sat, 28 Sep 2013, heroxbd wrote: I am revisiting this topic based on previous discussions[1,2,3]. There seems to be a constant need for toolchain with a new EAPI. The only block is how can we upgrade from an ancient system?, don't bump or the upgrade path will be break. Let's figure out a solid upgrade path consciously, with a test farm of ancient systems, and then bump the EAPI of toolchain. The upgrade path is not at all what is blocking this. In its 20130409 meeting, the council has (unanimously) decided: EAPIs 0 to 2 are no longer required for the upgrade path of users' systems. The reason why toolchain packages are still at EAPI 0 was explained in this posting: http://thread.gmane.org/gmane.linux.gentoo.project/2369/focus=2377 AFAICS, changing that is entirely the task of the toolchain team. Thank you for the clarification, Ulrich. Yes, it is entirely the task of the toolchain team, and looks like heroxbd joined the toolchain team and would like to push the rest of his team for this update. Something I greatly thank him for. I don't think any dev wants to (or really could) force toolchain to update individually, however, if motivated people want to join the team and help, his question appeared to be will it be permitted to be updated. Can't agree with you more. It's just a starting point, though. I still don't have a clear plan yet. After reading carefully the thread Ulrich pointed out, it seems that refactoring ebuild/eclass is invevitable, which calls for an overlay to carry it on. While I'm not nearly good enough to detail how this should happen exactly, please, may I beg, do an eclass revision for this. The fact that this hasn't been done clearly implies it is a lot of work. Let's not risk stable, let's simply make toolchain-r1.eclass or whatever, and bump that to eapi5. At the end of the day, this allows working and testing without odd issues, and if everyone really hates that idea you can simply drop the changes into the original eclass when it's all done. Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSR5V3AAoJEKXdFCfdEflKDcMP/0B01NSlVaTEM6oDIF324YNP p1G1vNVh86avVCL+0sLfmDPID547qWZOfemoids94xemrvyVYnJFccvtg7KBH+ck k4h/LJ2pTEvCGiL3KyUngYc6XN3YMwOHJsRD+jr0cmYG+GG0Lm5UUb73PPhgLtOv Ltrm4B68w3x1qqucrd3/PgBF7tfjoBdvB8XqkJ+u9RoMFfFb2BUH3n6VZ2Ngkzup BU5PaakC8tBGhZvkLrd81RHTY7iHuM5HGh4ZK0GSfVsq+pYIwFpWztKGcSQmEpxe oLgMZD2g5GAykkUhzcrvc6p091wsOylenAgnhZZL2cy2pZE99TLTUw6y/Q7+HUiN mKdXG/JbXQ/FmkhqVivvWM43g3bumEvYub5EegUa6MGrHjCqRjsO+GQq68CGTbMq TYpZXUGtCdAdMIyvk6wMhTWlrO2TQmakkj/tqHif1TsyVIIYZlTKLosftqxVbpxd 54Mr1oI+LM7oHGghy5/7BJz0V0U7BWIXiDBBf4HJ1k4gybkRBqCx7I+YSYib9ZZg jvHwJv9kiksduO5dQk/NmKgWgmyBTaYzZYPvxJyXp2uzk3Nmgf7JAwN2AHuUrFXZ 5LLwPC36bwEyAdKABHwIZsVdquBm2smFLIFy4oMoxcmEHBaOmOKBSrIKN0iLPYnD ZfpgorrlwCLdiqV+VeKU =jY8E -END PGP SIGNATURE-
