Re: [gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
On 27 September 2013 08:02, Martin Vaeth va...@mathematik.uni-wuerzburg.dewrote: For those which are provided by perl itself, you could have a corresponding useflag of dev-lang/perl and make a use dependency: If the main perl tarball does not provide the package, the perl ebuild can pull in the corresponding package as a dependency. That would be horrible. You'd have a massive list of USE flags, and you'd want *all* of them by default, and they'd have to pull the deps as PDEPENDS, because its impossible to have them as DEPENDS. And that would mean: X package wants Module::Build, so not only do you have to declare a dependency on Module::Build somehow, thats controlled by a USE flag, so maybe rebuild the entirety of Perl, just to install one thing that can be installed seperately from Perl. Also, instead of having the logical thing when Module::Build does get fully removed from perl, that we can simply remap the virtual to always pull from perl-core/Module-Build, we'd have to re-write every package in tree that used Module-Build. I was asking for solutions that reduce work, not increase it =p And when you wanted a specific version of a dual life module, you'd be completely out of luck. ( This is a problem with Module::Build, Test-Simple and ExtUtils::MakeMaker, because people regularly depend on specific versions of those things ) This is appropriate if something really needs a newer version, but not just because something *must* depend on the virtual only because some perl versions do not provide it. Worse than that I'm afraid, things that are virtualled are virtualled because upstream can and will depend on a specific version of that thing, and time to time, those versions are available only via CPAN, not via the present version of Perl And other times, upstream will depend on an explicit version which is available only in specific versions of perl, and virtuals are the only tool we have at present to mitigate these problems. And more, there is the growing list of modules that may be presently installed with perl, but are slated to stop being shipped with perl in a future release of perl. That means things that don't depend on the virtuals *now* will be broken when that version of perl ships, and its much, much easier to use the virtuals to resolve this problem, as opposed to tracking down all the modules that need to be fixed, and inlining a big list of conditional dependencies in each and every module that uses such a package. -- Kent
Re: [gentoo-dev] [RFC] Policy for migrating library consumers to subslots
Am Donnerstag, 26. September 2013, 20:11:04 schrieb Kent Fredric: On 27 September 2013 05:57, Ciaran McCreesh ciaran.mccre...@googlemail.comwrote: virtual/perl-* is self-inflicted. How would you recommend it? How about doing someting eclass-based, similar to add_kdebase_dep, and let the eclass carry the list of modules present inside the base perl distro? -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Policy for migrating library consumers to subslots
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. Well, the best technical solution for this is probably subslot dictionaries as suggested in bug 462138. Then, for each library a separate subslot could be declared, and programs can only be rebuilt if really needed. However, 1) I see this as a measure only for special cases, since it once again increases the maintainer burden. Going from subslot to subslot dictionary should only be done in a package if it's really worth the effort. 2) Maybe we should consider decoupling the subslot from the slot then. I.e. introducing a separate variable SUBSLOT. https://bugs.gentoo.org/show_bug.cgi?id=462138 -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Policy for migrating library consumers to subslots
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?
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.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
Sorry if this is duplicate: I repost since I cannot see it after a few hours. Kent Fredric kentfred...@gmail.com wrote: On 27 September 2013 08:02, Martin Vaeth va...@mathematik.uni-wuerzburg.dewrote: For those which are provided by perl itself, you could have a corresponding useflag of dev-lang/perl and make a use dependency: If the main perl tarball does not provide the package, the perl ebuild can pull in the corresponding package as a dependency. That would be horrible. You'd have a massive list of USE flags, and you'd want *all* of them by default, and they'd have to pull the deps as PDEPENDS, because its impossible to have them as DEPENDS. Why is this horrible? Perhaps there is a misunderstanding. You would need only those useflags which are possibly not provided by the corresponding perl version: The package dependent on a feature could just use e.g. DEPEND=dev-lang/perl[perl_module_Term_ANSIColor(+)] And concerning the number of use-flags, it might be worth thinking about a USE_EXPAND=perl_module. so maybe rebuild the entirety of Perl, just to install one thing that can be installed seperately from Perl. If the common flags are enabled by default, this would only involve users who have a serious reason (e.g. space issues) to disable some modules. Yes, these users would have to rebuild unnecessarily if they change their mind later on. I would compare disabling these modules with something like setting USE=minimal for other packages; users should know what they are doing if they use this. Also, instead of having the logical thing when Module::Build does get fully removed from perl, that we can simply remap the virtual to always pull from perl-core/Module-Build, we'd have to re-write every package in tree that used Module-Build. My idea is to keep this in the perl ebuilds forever: According to the perlversions which are still in the tree, it will take dozens of years until all perl versions providing Module-Build have vanished from the tree, and only afterwards it makes sense to think about such a change. This is a problem with Module::Build, Test-Simple and ExtUtils::MakeMaker, because people regularly depend on specific versions of those things My suggestion was explicitly about modules for which ebuilds do not require an explicit version. For those few(!) modules for which particular versions are needed, perhaps the virtual might be kept. Alternatively, for such cases it might make sense to depend directly on the package, since the probability to save duplicate installation in such a case is rather low, anyway. Worse than that I'm afraid, things that are virtualled are virtualled because upstream can and will depend on a specific version of that thing 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 And I guess that in this list of (for the main tree, but even with eix -Z ... the list is hardly longer) 62 packages actually many fall into the class where the minimal version is provided by current stable perl version anyway so that actually the minimal version dependency is redundant. And more, there is the growing list of modules that may be presently installed with perl, but are slated to stop being shipped with perl [...] and inlining a big list of conditional dependencies in each and every module that uses such a package. I was not suggesting inlining the list into the dependency but only inlining the USE-flag into the (single) perl ebuild. Currently if I have a package which needs e.g. Term-ANSI-Color, but not in a particular version, if I do not want to install an unnecessary duplicate version, I must inline a dependency like || ( =dev-lang/perl-5.14 virtual/perl-Term-ANSIColor ) and possibly change this if perl-5.20 does no longer contain perl-Term-ANSIColor.
Re: [gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
On Fri, Sep 27, 2013 at 12:48 PM, Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote: I was not suggesting inlining the list into the dependency but only inlining the USE-flag into the (single) perl ebuild. Currently if I have a package which needs e.g. Term-ANSI-Color, but not in a particular version, if I do not want to install an unnecessary duplicate version, I must inline a dependency like || ( =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?
Re: [gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
On 28 September 2013 07:48, Martin Vaeth va...@mathematik.uni-wuerzburg.dewrote: Sorry if this is duplicate: I repost since I cannot see it after a few hours. Kent Fredric kentfred...@gmail.com wrote: On 27 September 2013 08:02, Martin Vaeth va...@mathematik.uni-wuerzburg.dewrote: For those which are provided by perl itself, you could have a corresponding useflag of dev-lang/perl and make a use dependency: If the main perl tarball does not provide the package, the perl ebuild can pull in the corresponding package as a dependency. That would be horrible. You'd have a massive list of USE flags, and you'd want *all* of them by default, and they'd have to pull the deps as PDEPENDS, because its impossible to have them as DEPENDS. Why is this horrible? Perhaps there is a misunderstanding. You would need only those useflags which are possibly not provided by the corresponding perl version: The package dependent on a feature could just use e.g. DEPEND=dev-lang/perl[perl_module_Term_ANSIColor(+)] And concerning the number of use-flags, it might be worth thinking about a USE_EXPAND=perl_module. Its just a Perl module here can be only 1 file, and worse, you'll have to mentally make sure the USE flags have the right interdependencies for USE flags that require other USE flags to work. And rebuilding all of perl to change the presence of one file, gives us a lot of cost, and no benefit. And it still has the problem if a user wants a version of something that we don't know where its going to come from for all time, ie: 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. This solution is presently worse than virtuals, because it requires every ebuild to be aware of the mess of how resolving dual life dependencies work. so maybe rebuild the entirety of Perl, just to install one thing that can be installed seperately from Perl. If the common flags are enabled by default, this would only involve users who have a serious reason (e.g. space issues) to disable some modules. Yes, these users would have to rebuild unnecessarily if they change their mind later on. I would compare disabling these modules with something like setting USE=minimal for other packages; users should know what they are doing if they use this. The problem there is you're breaking upstream, because you're breaking how upstream perceives perl to work. If such a list of USE flags existed, it would be a very strong recommendation that they *ALL* be turned on. And again, this essentially says modules that are dual lifed are pretended not to be so, unless you combine this approach with PDEPEND 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. Also, instead of having the logical thing when Module::Build does get fully removed from perl, that we can simply remap the virtual to always pull from perl-core/Module-Build, we'd have to re-write every package in tree that used Module-Build. My idea is to keep this in the perl ebuilds forever: According to the perlversions which are still in the tree, it will take dozens of years until all perl versions providing Module-Build have vanished from the tree, and only afterwards it makes sense to think about such a change. This is a problem with Module::Build, Test-Simple and ExtUtils::MakeMaker, because people regularly depend on specific versions of those things My suggestion was explicitly about modules for which ebuilds do not require an explicit version. For those few(!) modules for which particular versions are needed, perhaps the virtual might be kept. Alternatively, for such cases it might make sense to depend directly on the package, since the probability to save duplicate installation in such a case is rather low, anyway 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. In the event new modules do hit tree need something that is dual lifed, it is much less effort to add a virtual to the tree to communicate the dependency properly, much less effort than rehashing dev-lang/perl itself, adding a new USE flag, and causing a domino of recompiles to deploy a hand-full of files that may not even need compiling to work. Worse than that I'm afraid, things that are virtualled are virtualled because upstream can and will depend on a specific version of that thing As mentioned above, this involves only a relatively small number of virtuals. Here is how I got the list: eix --print-all-depends | sed
[gentoo-dev] Gentoo Upgrade Guide and EAPI
Dear Fellows, 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. Besides the upgrading guide[4] suggesting a chroot, rich0 had some experiences with a live overwriting of latest stage3 to /, recently I've heard from patrick of a script to bootstrap Gentoo lively on an existing system (be it Debian, Red Hat or an ancient Gentoo). Here is another alternative from Prefix (upgrading the kernel is mostly independent): a. we distribute a stage3 of Gentoo RAP(i.e. Prefix with libc), with EPREFIX pointing to, say, /tmp/upgrade b. sync the potage tree in the host system, switch it to the newest profile. c. PORTAGE_OVERRIDE_EPREFIX=/ /tmp/upgrade/usr/bin/emerge -e world It has the same solidity as the chroot while being easier without the need to mount back and forth. It can track installed files properly as opposed to overwriting /. This needs a lot of work to do the testing. At the same time, there are definitely a dozen of developers who want to bump the EAPI of toolchain. Let's share the workload. vapier, if we can figure out a solid and easy solution for upgrading ancient Gentoo, would you agree on bumping the EAPI of toolchain? Cheers, Benda 1. http://thread.gmane.org/gmane.linux.gentoo.devel/86803 2. http://article.gmane.org/gmane.linux.gentoo.devel/73767 3. http://article.gmane.org/gmane.linux.gentoo.project/2841 4. http://www.gentoo.org/doc/en/gentoo-upgrading.xml
