The eclectic package has some extra features we could incorporate into eselect, namely the alternatives module. It does what everything the skel.bash.in and some extra: * add an importance ranking scheme for the different implementations * add update and unset actions, useful for ebuilds on pkg_postinst and pkg_prerm stages * add a possibility to generate a script to source that could be used for any user. This last bit needs some work I think. Patch to convert to eselect follows, but we would have to sort out the copyright issues with eclectic devs.
Created attachment 257274 [details, diff] eselect.alternatives.patch
Created attachment 257275 [details] alternatives-2.eclass an eclass derived from alternatives.exlibs. Adding a new eselect module is simply done with something like alternatives_for blas atlas 0 \ "/usr/$(get_libdir)/libblas.so" "libf77blas.so" \ "/usr/$(get_libdir)/libblas.a" "libf77blas.a" where 0 is the importance number.
We need the copyright assigned to the Gentoo Foundation. Before that, I won't even look at attached patches, because I may have to reimplement the module from scratch.
(In reply to comment #3) > We need the copyright assigned to the Gentoo Foundation. Why is this needed?
(In reply to comment #4) > Why is this needed? That's simply the same standard that we require for contributed ebuilds, i.e. it should have a Gentoo header (however, GPLv2 or later for eselect modules). Has anyone asked the authors?
(In reply to comment #2) > Adding a new eselect module is simply done with something like > > alternatives_for blas atlas 0 \ > "/usr/$(get_libdir)/libblas.so" "libf77blas.so" \ > "/usr/$(get_libdir)/libblas.a" "libf77blas.a" > > where 0 is the importance number. But that command is called from several packages? I don't understand yet how an eselect module can be added, without creating it as an orphan file.
This things has been in use in the sci overlay for all long time and I see a lot of eselect modules, which could be replaced by this one (vi, sh, awk, just to name a few.) So what is the status? Sebastien: From where is alternatives.bash coming? Was it part of dpkg?
Status is that (AFAIK) there's still no solution for the orphan files issue. I have some ideas how to solve it (basically, we need to generalize how a module can announce itself to the eselect core), but haven't found the time to implement it. It would also help if the copyright issue was sorted out, so that we would know if the existing code can be used as a starting point.
most of the code was a translation from exherbo eclectic tools (which was the original eselect). there are other minor issues with it: the negative ordering, and when an update of a package is done, we have to make sure the same eselect module implementation is kept. Probably the best for us would be to extend the skel functions in eselect to mimic this alternative behaviour, which could solve the copyright issue and making it more friendly.
What needs to be done here? I would like to see progress here. Can I do something?
I add most of the eclass functionality to the eselect module directly. Now one can directly use the whole module in an out-of-portage fashion to create own alternatives on a system. WE will test the code for a month and then I will make the manpage and everything ready for review and inclusion.
Ah forgot, current code lives at https://github.com/gentoo-science/eselect in case someone likes to comment.
(In reply to Justin Lecher from comment #12) > Ah forgot, current code lives at https://github.com/gentoo-science/eselect > in case someone likes to comment. Does this solve the problem of orphan files (see comment #8)?
(In reply to Ulrich Müller from comment #13) > (In reply to Justin Lecher from comment #12) > > Ah forgot, current code lives at https://github.com/gentoo-science/eselect > > in case someone likes to comment. > > Does this solve the problem of orphan files (see comment #8)? I have added a remove function for an alternative. When removing a provider the update function function is called. If update doesn't return the alternative is removed completely. (Actually I need to upgrade the code for the more finer return code for failure and not provider) https://github.com/gentoo-science/eselect/blob/alternatives/libs/alternatives.bash.in#L154
My test are working with current code >>> Unmerging (1 of 2) sci-libs/blas-reference-20131116-r1... * Removing reference alternative module for blas, current is eigen >>> Unmerging (2 of 2) dev-cpp/eigen-3.2.4... * Removing eigen alternative module for blas, current is (none) * Cleaning up unused alternatives module for blas # find /etc/env.d/alternatives/ /usr/share/eselect/modules/auto/ find: ‘/etc/env.d/alternatives/’: No such file or directory /usr/share/eselect/modules/auto/
(In reply to Justin Lecher from comment #14) > I have added a remove function for an alternative. When removing a provider > the update function function is called. If update doesn't return the > alternative is removed completely. Removing orphans isn't really a solution. They created, in the first place. At least, not in /usr/.
(In reply to Ulrich Müller from comment #16) > Removing orphans isn't really a solution. They created, in the first place. > At least, not in /usr/. s/They created/They shouldn't be created/
(In reply to Ulrich Müller from comment #16) > Removing orphans isn't really a solution. They created, in the first place. > At least, not in /usr/. Any idea how do work without the automatically created files?
(In reply to Justin Lecher from comment #18) > Any idea how do work without the automatically created files? Unfortunately, no. Otherwise there would have been progress here.
CCing QA team. In a nutshell: Would it be o.k. for eselect to create modules (that is executable bash scripts) in the live system, if these scripts are orphan files, i.e., not owned by any package? IIUC, the current code creates these modules in /usr/share (but maybe /var/lib would be more appropriate).
(In reply to Ulrich Müller from comment #20) > CCing QA team. > > In a nutshell: Would it be o.k. for eselect to create modules (that is > executable bash scripts) in the live system, if these scripts are orphan > files, i.e., not owned by any package? No, it's not ok and we should avoid that whenever possible. In fact, whenever I see those, I am trying to find a solution on making them owned by some package. > IIUC, the current code creates these modules in /usr/share (but maybe > /var/lib would be more appropriate). Yes, /var is more appropriate for unowned files. However, I don't see why we couldn't own those files via some 'common' package.
(In reply to Michał Górny from comment #21) > Yes, /var is more appropriate for unowned files. However, I don't see why we > couldn't own those files via some 'common' package. Because these files are volatile: with each eselect module installed or removed from system (or to be more precise when at least some alternative is present or all of them are removed) this "common" package will have to be rebuild. This is insane especially accounting for how slow portage is (as well as all known alternatives).
(In reply to Andrew Savchenko from comment #22) > (In reply to Michał Górny from comment #21) > > > Yes, /var is more appropriate for unowned files. However, I don't see why we > > couldn't own those files via some 'common' package. > > Because these files are volatile: with each eselect module installed or > removed from system (or to be more precise when at least some alternative is > present or all of them are removed) this "common" package will have to be > rebuild. This is insane especially accounting for how slow portage is (as > well as all known alternatives). Yes, because this is performance-critical. Users switch implementations every minute. But anyway, weren't we talking about some generated bash scripts (eselect modules) that would be created once per 'package group'?
The auto module generation is build into eselect itself. So you are able to add you own provider or whole alternative as you like. With this, /var/lib/ is the correct location. But I am not sure, whether it should really be owned by a package. I see as "application generated data" and that's it. The actual provider definition will always be owned by a specific package.
(In reply to Justin Lecher from comment #24) > The auto module generation is build into eselect itself. So you are able to > add you own provider or whole alternative as you like. With this, /var/lib/ > is the correct location. But I am not sure, whether it should really be > owned by a package. I see as "application generated data" and that's it. > The actual provider definition will always be owned by a specific package. These provider definitions contain the complete information necessary to generate the module, right? I wonder if the module couldn't be generated on the fly (and in memory) when eselect is called. As mgorny has noted, there is nothing performance critical here.
(In reply to Ulrich Müller from comment #25) > These provider definitions contain the complete information necessary to > generate the module, right? no, these are just the set of symlinks to files each provider provides. So this comes and goes with the actual files coming and going. eselect gathers the list of providers for each alternative as the alternative is used. > I wonder if the module couldn't be generated on the fly (and in memory) when > eselect is called. As mgorny has noted, there is nothing performance > critical here. But eselect needs to know that the alternative exists at all and that means the module needs to be generated/installed. So we cannot generate them onthefly.
<qa hat> I prefer to not create orphan files in the first place, but if it improves some area (in this case it removes the requirement for some additional eselect-$provider ebuilds, if i see it right), then i accept them as long as they are still properly monitored and finally removed, if not used anymore. For the location /var/lib seems to be the best match. </qa hat>
After some discussion I set the following header +# Copyright (c) 2005-2015 Gentoo Foundation +# Copyright (c) 2008 Mike Kelly +# Copyright (c) 2009-2013 David Leverton +# Copyright (c) 2009-2014 Bo Ørsted Andresen +# +# This file is part of the 'eselect' tools framework. +# +# eselect is free software: you can redistribute it and/or modify it under the +# terms of the GNU General Public License as published by the Free Software +# Foundation, either version 2 of the License, or (at your option) any later +# version. +# +# eselect is distributed in the hope that it will be useful, but WITHOUT ANY +# WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR +# A PARTICULAR PURPOSE. See the GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License along with +# eselect. If not, see <http://www.gnu.org/licenses/>.
We will move the autogenerated files to /var/lib. That hasn't been done yet, as we need to coordinate with the eselect package in the overlay to not break users setup. I will drop a note once done. @eselect team aka ulm, please take a look into the code.
We've discussed this in detail with heroxbd and ulm. We've determined that the original motivation of including this, that is blas/lapack, is not suitable for an eselect module since they are used by packages at build time. Those uses really require a proper solution based on USE flags to select a specific implementation to build against and USE dependencies to prevent two implementations from being used simultaneously in a single linked executable. Is there any other use case pursuing the inclusion of this module?
(In reply to Michał Górny from comment #30) > We've discussed this in detail with heroxbd and ulm. We've determined that > the original motivation of including this, that is blas/lapack, is not > suitable for an eselect module since they are used by packages at build time. > > Those uses really require a proper solution based on USE flags to select a > specific implementation to build against and USE dependencies to prevent two > implementations from being used simultaneously in a single linked executable. > > Is there any other use case pursuing the inclusion of this module? I've always supported this route and thought it to be more robust. This should be done imo like the python eclasses, with a LAPACK_COMPAT variable, which adds proper dependencies to a ${LAPACK_DEPS} variable. Unfortunately, the whole Sci community disagrees with me, and they prefer mpi.eclass-like solutions, where all libs can be swapped out transparently and ABI issues are just papered over, because it "seems to have worked just fine".
