Re: [gentoo-dev] Maintainer needed for dev-tcltk/expect
On 16/12/10 21:16, Mike Frysinger wrote: On Thursday, December 16, 2010 03:01:58 justin wrote: the tcltk herd is nearly dead. I am fixing bugs there and I am getting the queue down to an excaptable number. The only package which makes me headaches is dev-tcltk/expect. It seems, that there are quite some devs who are using this package. Could anyone of them stand up and take the maintainership for it? This would be a great help for me! i do like expect, and tcl deserves some special love. i'll see about doing a round of bug squashing with it. -mike Thanks Mike, that helps a lot. signature.asc Description: OpenPGP digital signature
[gentoo-dev] What are || ( ) dependencies?
How should a dependency like || ( a b c ) be interpreted? Traditionally, it's been described as something like: * if a matches an installed package, a * otherwise, if b matches an installed package, b * otherwise, if c matches an installed package, c * otherwise, if a is installable, a * otherwise, if b is installable, b * otherwise, if c is installable, c * otherwise, error Things get messier when you've got || ( a b-2.1 ) and b-2.0 is installed and a is not. Should b be upgraded to 2.1, or should a be selected? What about if you decide upon a early on, and then later on something hard-depends upon b? What about if you've got || ( a[foo] b ) and a[-foo] is installed? As a result of things like this, Portage has had various different sets of heuristics over time, and Paludis has had a different set. This is causing problems. Specifically, consider a dependency like the following, which is present in quite a few ebuilds: || ( x11-libs/libX11-1.3.99.901[xcb] =x11-libs/libX11-1.3.99.901 ) Paludis currently interprets this as I prefer 1.3.99.901, but will also accept =1.3.99.901. In particular, if 1.3.99.901[xcb] is already installed, libX11 won't be upgraded. Some Portage versions also do this, and others don't. There's one easy fix, which solves this and every other possible convoluted case (and some of those can be fairly horrible...): require ebuild developers to always list 'best' things leftmost. So if you're doing || ( =a-2 a-2 ) then you must put the = dep first (even if the = version is masked -- that's guaranteed to work). If the dependency is rewritten like this then all the ambiguity goes away: || ( =x11-libs/libX11-1.3.99.901 x11-libs/libX11-1.3.99.901[xcb] ) The other option is that we mandate a particular selection algorithm for || ( ) dependencies. This is a nuisance, for three reasons: * different Portage versions have done different things * it prevents the package mangler from doing something clever or offering additional features * every algorithm will do the wrong thing for certain combinations of dependencies if not given any preference information So would anyone be especially opposed to making best leftmost an explicit requirement, enforced by repoman where possible (at least for the = / case)? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] What are || ( ) dependencies?
Am 17.12.2010 16:25, schrieb Ciaran McCreesh: So would anyone be especially opposed to making best leftmost an explicit requirement, enforced by repoman where possible (at least for the = / case)? Why can't the PM handle = / cases itself? Sebastian
Re: [gentoo-dev] What are || ( ) dependencies?
On Fri, 17 Dec 2010 17:27:05 +0100 Sebastian Luther sebastianlut...@gmx.de wrote: Am 17.12.2010 16:25, schrieb Ciaran McCreesh: So would anyone be especially opposed to making best leftmost an explicit requirement, enforced by repoman where possible (at least for the = / case)? Why can't the PM handle = / cases itself? Because things are almost never as simple as 'just' = / . You can add in clever trickery to deal with very specific cases, but the second someone throws things off by adding in a use dependency or a third package, things get weird. Consider a variation on the original case: || ( a-2 =a-2[x] ) where the user has specified -x for a. What should happen then? What about || ( a-2[x] b =a-2 ) ? Should that be rewritten in the same way? What about || ( a-2[x] ( =a-2 b ) ) ? Should the package mangler be clever enough to figure that one out too? What if b isn't already installed there? Which is really the problem: clever heuristics get extremely complicated very quickly, and they're never enough. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] What are || ( ) dependencies?
On 12/17/10 4:25 PM, Ciaran McCreesh wrote: As a result of things like this, Portage has had various different sets of heuristics over time, and Paludis has had a different set. Generally it seems fine to have different heuristics (I'll comment on the specific problem below). Paludis currently interprets this as I prefer 1.3.99.901, but will also accept =1.3.99.901. In particular, if 1.3.99.901[xcb] is already installed, libX11 won't be upgraded. Some Portage versions also do this, and others don't. I don't understand why we can't upgrade libX11 in that case. Shouldn't emerge -uDNa world (or its Paludis equivalent) think like this: Okay, I have libX11 installed here, and a more recent version is available. The more recent version satisfies this || () dependency, so just update it. There's one easy fix, which solves this and every other possible convoluted case (and some of those can be fairly horrible...): require ebuild developers to always list 'best' things leftmost. Sounds reasonable. The other option is that we mandate a particular selection algorithm for || ( ) dependencies. Doesn't that somehow contradict the idea that || () lists equivalent dependencies? Maybe we should fix the heuristics. In this specific case, it seems reasonable to still upgrade libX11, right? So would anyone be especially opposed to making best leftmost an explicit requirement, enforced by repoman where possible (at least for the = / case)? I don't think that = / case is enforceable by repoman (i.e. that we always prefer the more recent version of a package). However, saying that the preferred dependency should be listed first sounds reasonable. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] What are || ( ) dependencies?
Am 17.12.2010 17:37, schrieb Ciaran McCreesh: On Fri, 17 Dec 2010 17:27:05 +0100 Sebastian Luther sebastianlut...@gmx.de wrote: Am 17.12.2010 16:25, schrieb Ciaran McCreesh: So would anyone be especially opposed to making best leftmost an explicit requirement, enforced by repoman where possible (at least for the = / case)? Why can't the PM handle = / cases itself? Because things are almost never as simple as 'just' = / . You can add in clever trickery to deal with very specific cases, but the second someone throws things off by adding in a use dependency or a third package, things get weird. I thought we were talking about the simplest case here, that is a list of atoms for the same cat/pkg. Consider a variation on the original case: || ( a-2 =a-2[x] ) where the user has specified -x for a. What should happen then? What about || ( a-2[x] b =a-2 ) ? Should that be rewritten in the same way? What about || ( a-2[x] ( =a-2 b ) ) ? Should the package mangler be clever enough to figure that one out too? What if b isn't already installed there? What would repoman enforce here? Which is really the problem: clever heuristics get extremely complicated very quickly, and they're never enough. Agreed. Sebastian
Re: [gentoo-dev] What are || ( ) dependencies?
On Fri, 17 Dec 2010 17:49:22 +0100 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: Paludis currently interprets this as I prefer 1.3.99.901, but will also accept =1.3.99.901. In particular, if 1.3.99.901[xcb] is already installed, libX11 won't be upgraded. Some Portage versions also do this, and others don't. I don't understand why we can't upgrade libX11 in that case. Shouldn't emerge -uDNa world (or its Paludis equivalent) think like this: Okay, I have libX11 installed here, and a more recent version is available. The more recent version satisfies this || () dependency, so just update it. That's not really how the Paludis resolver thinks. Basically, when it encounters a || ( ) dependency, it selects one of the children based upon a scoring algorithm. At the time it encounters the || ( ) dependency, it doesn't know for sure that it's allowed to upgrade libX11, since a later ebuild might hard-dep upon the lower version. Now, I *could* make it treat the very specific case of || ( a-1[x] =a-1 ) as being a single dep spec like a[either 1[x] or =1], but that doesn't really help as soon as someone does this: || ( a-1[x] ( =a-1 b ) ) which looks a lot like something someone would do. In this specific case, it seems reasonable to still upgrade libX11, right? In this very specific case, rewriting || ( a[stuff] a[otherstuff] ) to be like a[stuff || otherstuff] would solve the problem. But even slightly altering the dependencies would break this. So the question is to what degree a package mangler is required to be clever. So would anyone be especially opposed to making best leftmost an explicit requirement, enforced by repoman where possible (at least for the = / case)? I don't think that = / case is enforceable by repoman (i.e. that we always prefer the more recent version of a package). It's at least detectable... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] What are || ( ) dependencies?
On Fri, 17 Dec 2010 17:56:21 +0100 Sebastian Luther sebastianlut...@gmx.de wrote: Why can't the PM handle = / cases itself? Because things are almost never as simple as 'just' = / . You can add in clever trickery to deal with very specific cases, but the second someone throws things off by adding in a use dependency or a third package, things get weird. I thought we were talking about the simplest case here, that is a list of atoms for the same cat/pkg. Here's the problem: if the package mangler gets this right (which afaik both Portage and Paludis do): || ( a-1 =a-1 ) you might naively expect it to get these right too: || ( a-1 ( =a-1 b ) ) || ( a-1 a-1[x] ) # where a[-x] is the current user configuration which it probably won't, and even if it does, it will get other minor variations on these themes wrong. What about || ( a-2[x] ( =a-2 b ) ) ? Should the package mangler be clever enough to figure that one out too? What if b isn't already installed there? What would repoman enforce here? For that case, it probably couldn't detect it. But getting repoman to yell at people for the simple cases at least would probably help people to learn that they should always go best-leftest. Part of the problem here is that developers don't seem to know about the whole leftmost thing, and the heuristics we've all put in mean they can quite often get away with not knowing it. It also doesn't help that it's not really documented anywhere. It's not in the devmanual, it's not in PMS (and it's hard to put it there, assuming we're not requiring a particular selection algorithm), and the stuff in ebuild(5) for || dependencies is just plain wrong. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] What are || ( ) dependencies?
On 12/17/10 18:09, Ciaran McCreesh wrote: On Fri, 17 Dec 2010 17:56:21 +0100 Sebastian Luther sebastianlut...@gmx.de wrote: Why can't the PM handle = / cases itself? Because things are almost never as simple as 'just' = / . You can add in clever trickery to deal with very specific cases, but the second someone throws things off by adding in a use dependency or a third package, things get weird. I thought we were talking about the simplest case here, that is a list of atoms for the same cat/pkg. Here's the problem: if the package mangler gets this right (which afaik both Portage and Paludis do): || ( a-1 =a-1 ) you might naively expect it to get these right too: || ( a-1 ( =a-1 b ) ) || ( a-1 a-1[x] ) # where a[-x] is the current user configuration which it probably won't, and even if it does, it will get other minor variations on these themes wrong. There are multiple valid solutions. The default heuristic for right seems to be highest version, but other solutions fulfill the dependency specification too. Part of the problem here is that developers don't seem to know about the whole leftmost thing, and the heuristics we've all put in mean they can quite often get away with not knowing it. I'm not sure if I want that enforced, but a suggestion that left-to-right order may be used by the package manager sounds like a reasonable idea. It also doesn't help that it's not really documented anywhere. It's not in the devmanual, it's not in PMS (and it's hard to put it there, assuming we're not requiring a particular selection algorithm), and the stuff in ebuild(5) for || dependencies is just plain wrong. Patches Welcome? ;)
[gentoo-dev] Old-style virtuals blocking feature needed for virtual/mta
* Ciaran McCreesh ciaran.mccre...@googlemail.com: Is there anything in particular holding back replacing most or all of the remaining old-style virtuals with new 'package' virtuals? There's still that stupid !virtual/blah thing to deal with. Old style virtual providers are allowed to block their own virtual to mean there must not be any other provider of this installed (although it's not clear what that means if anything other than a simple !virtual/pkg is used). Anything doing that would now have to explicitly list its own blocks. Arguably, this is a good thing, since you'd have to say exactly what you do and don't work with. This is a problem for virtual/mta. As long as we have to block all other mailers with the sendmail compatibility interface to avoid collisions, adding explicit blockers for mailers in all repositories is unlikely to work well. The former mailwrapper/mailer-config tools solved this problem but they were too slow. Once we have a better alternatives system (#348843) the problem might be sorted out (as you probably know). -- Regards Torsten
Re: [gentoo-dev] [warning] the bug queue has 118 bugs
On Wednesday 15 of December 2010 17:03:12 Matt Turner wrote: On Wed, Dec 15, 2010 at 12:25 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: By the way, we have a nice team of arch and herd testers - how about encouraging them to wrangle some bugs? Yeah, I just came here to say this. One certainly doesn't need to have completed the developer quizzes to sort bugs. Well, before I became developer, I had a quite unproductive discussion on IRC with Jeroen on that matter (jer opting for status quo and telling me I have no idea what bug wrangling is :P) It all started by Yngwin's post: http://forums.gentoo.org/viewtopic-t-702248-highlight-contributions.html Some ideas were proposed such as lowering requirements for bug wranglers or recruiting them as staff (so bypassing ebuild quizzes). -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [warning] the bug queue has 118 bugs
Maciej Mrozowski wrote: On Wednesday 15 of December 2010 17:03:12 Matt Turner wrote: On Wed, Dec 15, 2010 at 12:25 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: By the way, we have a nice team of arch and herd testers - how about encouraging them to wrangle some bugs? Yeah, I just came here to say this. One certainly doesn't need to have completed the developer quizzes to sort bugs. Well, before I became developer, I had a quite unproductive discussion on IRC with Jeroen on that matter (jer opting for status quo and telling me I have no idea what bug wrangling is :P) It all started by Yngwin's post: http://forums.gentoo.org/viewtopic-t-702248-highlight-contributions.html Some ideas were proposed such as lowering requirements for bug wranglers or recruiting them as staff (so bypassing ebuild quizzes). Well, I would be willing to get my feet wet at least. I'm disabled and been using Gentoo since the 1.4 days. If someone would be willing to put up with a few screw ups I would make, I could give it a go. If I really suck at it, you can kick me out. ;-) No hard feelings. I'm not sure how much I can do but maybe enough to help some at least. Someone is going to have to explain what I would be doing tho. That or a really smoking hot link to explain it all. dale signs his last will Dale :-) :-)
[gentoo-dev] Summary of suggested new features in EAPI=4
This is the summary of some problems and suggested new features in EAPI=4,
which would solve
these problems.
Problem #1: USE flags cannot contain . characters.
The following solutions have been suggested:
- Add support for . characters in USE flags in EAPI=4.
Problem #2: Files in profiles cannot use features from newer EAPIs.
The following solutions have been suggested:
- Add support for files with -${EAPI} extension in EAPI=4. These files
would use EAPI
specified in their filenames instead of EAPI of profile.
Example files:
package.mask-${EAPI}
package.use-${EAPI}
package.provided-${EAPI}
use.force-${EAPI}
use.mask-${EAPI}
package.use.force-${EAPI}
package.use.mask-${EAPI}
packages-${EAPI}
virtuals-${EAPI}
- Create new profiles using EAPI=4, remove all older profiles from
profiles.desc so that
repoman doesn't check older profiles, and deprecate older profiles.
Council should choose one of these solutions.
Problem #3: repoman doesn't allow stable packages to have optional dependencies
on unstable
packages (usually until these packages are stabilized).
Example of the problem:
If python_abis_2.7, python_abis_3.1 and python_abis_3.2 USE flags are
masked using
use.mask on given architectures until Python 2.7, 3.1 and 3.2 are stabilized on
these
architectures, then majority of reverse dependencies of Python won't be tested
with new
versions of Python.
The following solutions have been suggested:
- Add support for use.unsatisfiable and package.use.unsatisfiable files in
profiles in
EAPI=4. These files would cause that repoman would allow optional
dependencies on
packages potentially unsatisfiable in some configurations (e.g. on
stable-only systems).
- Create separate profiles for stable and unstable keywords. USE flags would be
masked in
stable profiles and unmasked in unstable profiles.
Council should choose one of these solutions.
There are already existing patches for Portage, which implement these
solutions, which are
suggested new features in EAPI=4.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] What are || ( ) dependencies?
On 15:25 Fri 17 Dec , Ciaran McCreesh wrote: How should a dependency like || ( a b c ) be interpreted? Traditionally, it's been described as something like: * if a matches an installed package, a * otherwise, if b matches an installed package, b * otherwise, if c matches an installed package, c * otherwise, if a is installable, a * otherwise, if b is installable, b * otherwise, if c is installable, c * otherwise, error Things get messier when you've got || ( a b-2.1 ) and b-2.0 is installed and a is not. Should b be upgraded to 2.1, or should a be selected? It depends ... see later. What about if you decide upon a early on, and then later on something hard-depends upon b? Then you're collapsing the graph too early. =) (speaking as an utter novice) What about if you've got || ( a[foo] b ) and a[-foo] is installed? See later again.. As a result of things like this, Portage has had various different sets of heuristics over time, and Paludis has had a different set. This is causing problems. Specifically, consider a dependency like the following, which is present in quite a few ebuilds: || ( x11-libs/libX11-1.3.99.901[xcb] =x11-libs/libX11-1.3.99.901 ) Paludis currently interprets this as I prefer 1.3.99.901, but will also accept =1.3.99.901. In particular, if 1.3.99.901[xcb] is already installed, libX11 won't be upgraded. Some Portage versions also do this, and others don't. Why is this a problem that needs to be resolved at the specification level rather than a difference between implementations? If a package manager is making strange choices, There's one easy fix, which solves this and every other possible convoluted case (and some of those can be fairly horrible...): require ebuild developers to always list 'best' things leftmost. So if you're doing || ( =a-2 a-2 ) then you must put the = dep first (even if the = version is masked -- that's guaranteed to work). If the dependency is rewritten like this then all the ambiguity goes away: I'd thought people already knew that this was typical behavior of an || group (as per the simple example in ebuild(5)), but you've said differently later in this thread. I certainly wouldn't mind documenting that left is best in cases where none are installed, since this has been expected behavior to those of us who do know. However, that doesn't resolve the case where a package is installed but is either too old or has a mismatched USE flag to the dep. It's not clear to me how this proposal would deal with the system-dependent components. I think whether a deep upgrade is requested (or otherwise directly targeting the dependency for possible upgrading) should impact the choice between = and . If no upgrade is desired, allow the dep to be fulfilled; otherwise attempt an upgrade to the newest version and see if it matches. For the mismatched case, I'd attempt to flip the USE unless that would produce a conflict with another package; in that case, pick the leftmost other fulfiller. || ( =x11-libs/libX11-1.3.99.901 x11-libs/libX11-1.3.99.901[xcb] ) The other option is that we mandate a particular selection algorithm for || ( ) dependencies. This is a nuisance, for three reasons: * different Portage versions have done different things * it prevents the package mangler from doing something clever or offering additional features * every algorithm will do the wrong thing for certain combinations of dependencies if not given any preference information I think this last point is one of the strongest ones. Humans may need to decide what's best for any specific package's dependencies. So would anyone be especially opposed to making best leftmost an explicit requirement, enforced by repoman where possible (at least for the = / case)? Not in the entirely ambiguous case, but things are trickier when one of the packages is installed, even in nonmatching version/USE. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpJzD1EkNdBv.pgp Description: PGP signature
Re: [gentoo-dev] Summary of suggested new features in EAPI=4
On 02:45 Sat 18 Dec , Arfrever Frehtes Taifersar Arahesis wrote: Problem #1: USE flags cannot contain . characters. This isn't a problem, it's an arbitrary statement of an antifeature. My understanding of the actual problem here is that you want to have some sort of USE flags for various Python versions with names containing periods, for usability. Perhaps you could expand on exactly what you want to do, so we can work together to figure out whether this is the best route to solve your problem. If the problem is handling which Python versions to build modules for, I'm wondering whether enhancing the eselect module to select *multiple* preferred versions might not be a better solution than EAPI changes. We've been having the same discussion for Fortran90 modules, and George Shapovalov mentioned that this is how he handled things for Ada (see gnat-related eclass/eselect mod). Problem #2: Files in profiles cannot use features from newer EAPIs. Could you explain how the eapi file in profiles does not address this? The 10.0 profiles are using it already with EAPI=2. I'll paste the description from the PMS to make it easier for anyone following along: 5.2.2 The eapi file A profile directory may contain an eapi file. This file, if it exists, must contain a single line with the name of an EAPI. This specifies the EAPI to use when handling the directory in question; a package manager must not attempt to use any profile using a directory which requires an EAPI it does not support. If no eapi file is present, EAPI 0 shall be used. The EAPI is not inherited via the parent file. Problem #3: repoman doesn't allow stable packages to have optional dependencies on unstable packages (usually until these packages are stabilized). This seems useful at first glance, but I'm wondering how big of a problem it really is and whether this solution is a bit overarchitected. Example of the problem: If python_abis_2.7, python_abis_3.1 and python_abis_3.2 USE flags are masked using use.mask on given architectures until Python 2.7, 3.1 and 3.2 are stabilized on these architectures, then majority of reverse dependencies of Python won't be tested with new versions of Python. Why does that have to be the case? Why not unmask them earlier but only make them available to ~arch ebuilds? I don't know of anyone who's actually done this, but setting IUSE based on ACCEPT_KEYWORDS being ~arch should be possible. There may be better or easier solutions. The following solutions have been suggested: - Add support for use.unsatisfiable and package.use.unsatisfiable files in profiles in EAPI=4. These files would cause that repoman would allow optional dependencies on packages potentially unsatisfiable in some configurations (e.g. on stable-only systems). - Create separate profiles for stable and unstable keywords. USE flags would be masked in stable profiles and unmasked in unstable profiles. Council should choose one of these solutions. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpxxXC9wphlv.pgp Description: PGP signature
Re: [gentoo-dev] Summary of suggested new features in EAPI=4
2010-12-18 03:48:26 Donnie Berkholz napisał(a): On 02:45 Sat 18 Dec , Arfrever Frehtes Taifersar Arahesis wrote: Problem #1: USE flags cannot contain . characters. This isn't a problem, it's an arbitrary statement of an antifeature. My understanding of the actual problem here is that you want to have some sort of USE flags for various Python versions with names containing periods, for usability. Perhaps you could expand on exactly what you want to do, so we can work together to figure out whether this is the best route to solve your problem. If the problem is handling which Python versions to build modules for, I'm wondering whether enhancing the eselect module to select multiple preferred versions might not be a better solution than EAPI changes. USE flags would allow to use USE dependencies to ensure that dependencies of given package have been installed for required Python versions. Problem #2: Files in profiles cannot use features from newer EAPIs. Could you explain how the eapi file in profiles does not address this? The 10.0 profiles are using it already with EAPI=2. I would like to use EAPI=4-specific syntax in a file in base profile (or somewhere else) to affect all profiles. If I have to rely on eapi files, then all non-deprecated profiles checked by repoman would have to use EAPI =4. Problem #3: repoman doesn't allow stable packages to have optional dependencies on unstable packages (usually until these packages are stabilized). This seems useful at first glance, but I'm wondering how big of a problem it really is and whether this solution is a bit overarchitected. Example of the problem: If python_abis_2.7, python_abis_3.1 and python_abis_3.2 USE flags are masked using use.mask on given architectures until Python 2.7, 3.1 and 3.2 are stabilized on these architectures, then majority of reverse dependencies of Python won't be tested with new versions of Python. Why does that have to be the case? Why not unmask them earlier but only make them available to ~arch ebuilds? There are already hundreds of stable ebuilds, which support unstable Python 2.7 (without explicit optional dependency on Python 2.7). The solution to problem #3 shouldn't require any changes in ebuilds. I don't know of anyone who's actually done this, but setting IUSE based on ACCEPT_KEYWORDS being ~arch should be possible. It would break invariance of metadata. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
