Re: [gentoo-dev] Summary of suggested new features in EAPI=4
On 18-12-2010 02:45:06 +0100, Arfrever Frehtes Taifersar Arahesis wrote: Problem #1: USE flags cannot contain . characters. The following solutions have been suggested: - Add support for . characters in USE flags in EAPI=4. Like Donnie said, this feels like a purely cosmetic change. I think that alone is not a good reason to do this. 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. I don't see the problem here actually. As soon as you're going to allow stable and unstable to be mixed, the concept of stable isn't worth much any more, IMO. If you want to have some experimental feature in some package, it can never be stable, unless it is e.g. USE-masked, and unmasking of the right package(s) is left as an excercise for the user. Your Python example only indicates to me how much of a mess it has actually become. For most other packages, it is quite normal that a new version is untested until it is stabilised, which means unstable users are the ones to find the problems, if any. The maintainer (and to an extent the arch teams) of course has a leading role in this. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Summary of suggested new features in EAPI=4
On 12/18/2010 01:57 AM, Fabian Groffen wrote: On 18-12-2010 02:45:06 +0100, Arfrever Frehtes Taifersar Arahesis wrote: Problem #1: USE flags cannot contain . characters. The following solutions have been suggested: - Add support for . characters in USE flags in EAPI=4. Like Donnie said, this feels like a purely cosmetic change. I think that alone is not a good reason to do this. 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. I don't see the problem here actually. As soon as you're going to allow stable and unstable to be mixed, the concept of stable isn't worth much any more, IMO. If you want to have some experimental feature in some package, it can never be stable, unless it is e.g. USE-masked, and unmasking of the right package(s) is left as an excercise for the user. Your Python example only indicates to me how much of a mess it has actually become. For most other packages, it is quite normal that a new version is untested until it is stabilised, which means unstable users are the ones to find the problems, if any. The maintainer (and to an extent the arch teams) of course has a leading role in this. I think the separate profiles for stable and unstable keywords approach is a clear winner here. With separate stable and unstable profiles, unstable users don't have to do any unmasking themselves. When it comes time to migrate things to stable, the arch teams simply update the stable profiles to behave like the unstable profiles. This approach also protects stable users from experiencing unsatisfied dependencies that the *.unsatisfiable approach would expose them to. -- Thanks, Zac
Re: [gentoo-dev] What are || ( ) dependencies?
On Fri, 17 Dec 2010 20:13:55 -0600 Donnie Berkholz dberkh...@gentoo.org wrote: 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) Yeah, but unfortunately, there's no way to figure out when too early is. What if it's one of a's dependencies that hard-depends upon b? Until you've decided upon something, you don't know what dependencies are going to be pulled in, so you're left having to make possibly incorrect decisions and then try to undo them later on if possible. 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, The problem's how you define strange choices. If dependencies aren't listed best-leftmost, every package manager makes strange choices for some combinations. Either this can be fixed by getting developers to always write things best-leftmost, or it can be fixed by mandating specific behaviour for all package managers for || ( ) deps. I'd much rather we did the former. 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. Well, we're running across a fair number of cases along the lines of the libX11 one https://bugs.gentoo.org/show_bug.cgi?id=348518 is what prompted the email -- it turns out vlc is by no means the only package doing this, though, which gives me two options for Paludis: add in a heuristic that gets that very specific case right (and update PMS requiring package manglers to do the same), or get people to list their deps the other way around. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: What are || ( ) dependencies?
On Fri, 17 Dec 2010 15:25:04 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: So would anyone be especially opposed to making best leftmost an explicit requirement, enforced by repoman where possible (at least for the = / case)? I already thought that was the case, so +1 from me. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Summary of suggested new features in EAPI=4
On Fri, 17 Dec 2010 20:48:26 -0600 Donnie Berkholz dberkh...@gentoo.org wrote: 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. Uhm... IUSE has to be metadata-invariant. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Lastrite: gnome-device-manager, devtray
# Samuli Suominen ssuomi...@gentoo.org (19 Dec 2010) # Graphical interface for sys-apps/hal. Removal in 30 days. gnome-extra/gnome-device-manager # Samuli Suominen ssuomi...@gentoo.org (19 Dec 2010) # Replaced by rox-base/rox-media, bug 313431, Comment #2 # Still using obsolete sys-apps/hal and gnome-base/gnome-mount, # bug 349012, Comment #1. # Removal in 30 days. rox-base/devtray
Re: [gentoo-dev] Re: What are || ( ) dependencies?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18-12-2010 18:35, Ryan Hill wrote: On Fri, 17 Dec 2010 15:25:04 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: So would anyone be especially opposed to making best leftmost an explicit requirement, enforced by repoman where possible (at least for the = / case)? I already thought that was the case, so +1 from me. I've been treating it that way for a long time. The KDE team used this feature at least one or two times, that I can recall, to reflect the change on preferred deps. I think one case was the move from monolithic to split Qt deps. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNDWLiAAoJEC8ZTXQF1qEPA8oP/3mGSBO3ojtBTn4mjQeqJFh3 z3bBQSx25QulgpZtn9oM5oYb6uxFY3Wh188THW548Bb+E6kKAYm6SlE7RxyoP0sz XNie8KcrMPCUfvbu1DaHdFzhnGh5Jrr9kYieQI8PRFxYLR1ucLAdLm07dX1MJ5VW Y0eFB0qRw9JP9JTLyFLNqj3j5x5Z97KE3CdLbenVfm8DcMHUgwKL5IChEFPZolcr nXWRDhh9JYNXIeb+13YW8b29XuJei1nJs8Gk1rsK1uKu//0y+mkwr/bzbDA+gpqs RcYwKc8HlZrNuLALXRUoIwx99Rhe3/JSuCfcHgXctTPCxPbZzaHYsjMIkp8EK392 R6yhENmUVTfzIrHkYGR4aoUcDjB/r7yxXN04W1A/r32e5QGy3fV5r80Ak7cFPhRv Xteg3BYtWhsVDzJucYgtyeFkCWXwz5ywOKpK6awVrp10ymmGD2FpYpLafCU/8rZM 8X9EdGII9OjPRDw1RUzao1WMoYwVbe5vmUOVp7N+F7mrwHB2VoXqKpkUAOrfrApZ QB6iHs+WM0q4WM+Bh9mGpsLyL/Xo+/Q996DdJ14m41RHYu4wEthzh4A2W3mqXjLH LwEdq1TCpz9+SVJ3TZNMf+SBl0aG3dyQW21IQyMGxX/zaiizuYOJ6rVhkYX0O9w3 BjGd7Gmv5LXEDScNfbaQ =PVWL -END PGP SIGNATURE-
[gentoo-dev] Lastrite: hal-cups-utils
# Samuli Suominen ssuomi...@gentoo.org (19 Dec 2010) # Orphaned package, still using deprecated HAL # Removal in 30 days, bug 344313 app-misc/hal-cups-utils
Re: [gentoo-dev] What are || ( ) dependencies?
On 12/17/2010 06:13 PM, Donnie Berkholz wrote: On 15:25 Fri 17 Dec , Ciaran McCreesh wrote: 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) This is the same kind of case as in bug 264434. We solved it in portage by putting || and virtual dependencies on stack, and delaying their evaluation until as late as possible. You may be able to dream up some corner cases where this approach doesn't help, but in practice it seems to help more often than not. [1] http://bugs.gentoo.org/show_bug.cgi?id=264434 -- Thanks, Zac
