Re: [gentoo-dev] sandbox-1.7 and static binaries
On Tuesday 31 March 2009 07:52:24 Mike Frysinger wrote: > partly because the QA notices about untraceable static binaries that > sandbox-1.6 emits, but mostly because i wanted to bust solar's balls, i did > a mini hack fest the other nite and added ptrace() support into sandbox for > static binaries. seems to work for me, but if someone notices something > new and freaky, you've been warned! some notes from the wild: - some packages might fail now that didnt before due to /etc/ld.so.* violations. no, this isnt a bug in sandbox. it was a bug that older sandboxes didnt catch it. every case ive seen so far means the package is wrongly running `ldconfig` on the entire tree during src_install(). this is a pointless waste of cpu time, i/o time, hawaii time, and other crap. disable it in your package. - tracing of multilib is supported (so 32bit x86 on 64bit x86_64 host) - parisc and blackfin are now supported - static binaries that violate sandbox are killed immediately. this is different from normal sandbox where the application is returned an error and it keeps on running. this is due to ptrace limitations where there is no way for the parent doing the tracing to tell the traced child to skip execution of the next syscall. our choices as the tracer are (1) let it happen and modify the syscall return or (2) kill it immediately. since (1) allows the syscall to occur (say something like unlink(/foo/bar), that clearly isnt acceptable. unless i missed something in ptrace in which case people should point it out to me. > side note, i think sandbox-1.6-r1 should be good for stable. only one > minor compliant about 1.6, and that's fixed in 1.6-r1. and this is in the process so if people found something wrong, please post it: https://bugs.gentoo.org/265376 -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] One-Day Gentoo Council Reminder for April
Le 09/04/2009 20:38, Donnie Berkholz a écrit : I don't particularly wish for this to happen Real Soon, but drafting a plan sounds like a good first step. OK, I'm looking forward to reading your draft. =) 1) migrate 2) party I don't really see what else should be in between steps 1 and 2. I definitely can give out a hand with #2 though. Rémi
[gentoo-dev] Re: EAPI-3 draft: slot operator support
On Thu, 9 Apr 2009 23:36:16 +0530 Nirbheek Chauhan wrote: > On Thu, Apr 9, 2009 at 10:15 PM, Tiziano Müller wrote: > > roughly 90% packages depending on one of: > > > > sys-libs/db > > Why the hell does this have so many slots in-tree? I am unaware of the > reasons for it. Horribly changed API every release? How does every > other distro handle sys-libs/db ? I know debian has four or five around at any given time. Others I'm not sure. > > dev-libs/boost > > Has one unmasked slot in-tree Soon to be four. > > dev-lang/python > > > > So, wait, you want to depend on specific slots of python and keep them > around, and manage all their related bugs? Isn't that exactly the > opposite of what python upstream suggests, and *ALL* distros do? Why have python slotted at all then? > > Besides: We wouldn't need the need_python_rebuild anymore, users could > > safely uninstall old sys-libs/db versions, old dev-libs/boost versions > > @preserved-libs. More generic, a low-level catch-all for library > breakages, and more convenient for users (rebuild as and when > possible, not *right now* lest everything break). We absolutely can _not_ be relying on preserved libs to save us. It's an umbrella for when the shit hits the fan. You still get to clean up afterwards. It doesn't know anything about interpreted languages (or anything but libraries for that matter). And it doesn't do jack for people uninstalling library slots that are still in use because it doesn't know what slot a package was built against in the first place, and that's exactly the case we're talking about here. > > and the list of packages to reinstall in python-updater boils down to > > what "paludis -u dev-lang/python:2.4" spits out as reverse-dependencies > > (or the corresponding portage command). > > You mean emerge -C dev-lang/python:2.4 ? That'll say "bai bai python". > > In any case, what is wrong with python_need_rebuild ? > > Slot operators need changes to the ebuilds, so does python_need_rebuild. > Slot operators need an EAPI bump for the ebuild, python_need_rebuild doesn't. > > So, isn't python_need_rebuild superior.. ? It's a package-specific workaround for the fact that we have no way of knowing what packages were built against a particular slot. We could implement it for every slotted library in the tree or we could make the workaround unnecessary. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 3 PMS Draft
Am Donnerstag, den 09.04.2009, 13:13 -0400 schrieb Richard Freeman: > Ciaran McCreesh wrote: > > > > Most packages that have tests have working tests. For those that don't, > > the tests have to be restricted. All this proposal does is ensures that > > that happens in a progressive, incremental and safe way. > > > > I agree with this point - failing tests are more the exception than the > rule. > > Looking at my system the only packages I'm skipping tests for are: > openldap|parted|orbit|samba|kpilot|nautilus|libksieve|karm|libbonoboui|gnome-vfs|pkgconfig|pam|coreutils|pan|mono|glibc|gettext|curl No need to skip samba, there are no tests anymore. > > Some of those might be fixed now. > > > If packages are failing tests, either it's a legitimate reason, in > > which case it needs to be fixed, or it's not, in which case it needs to > > be restricted. The problem is, currently there's no way for users to > > know which is which. With an EAPI mandated src_test, users will know > > that any failure that gets to them is legitimate. > > Hence my having the list posted above (which is just the ones I use that > I've found problems with). > > I also would like to say that the "slow-test" compromise sounds like a > good idea. > > A fast-running automated test routine is a good sanity check to show > that nothing went wrong during the build. Maybe the user has some odd > version of a dependency that no developer checked with the new package. > Arch testers can't test every combination of dependencies, > configurations, use-flags, etc. > > I would think that this might even cut down on user-reported issues. > Better to find out that a package has a problem BEFORE it is actually > installed. > > If a user is going to spend 10 minutes building a bunch of packages > spending another 30-60 seconds on some basic tests doesn't sound > unreasonable. We could also make it easy for users to disable testing > entirely if they want to live dangerously. > signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] EAPI-3 draft: slot operator support
Am Donnerstag, den 09.04.2009, 23:36 +0530 schrieb Nirbheek Chauhan: > On Thu, Apr 9, 2009 at 10:15 PM, Tiziano Müller wrote: > > roughly 90% packages depending on one of: > > > > sys-libs/db > > Why the hell does this have so many slots in-tree? I am unaware of the > reasons for it. Horribly changed API every release? How does every > other distro handle sys-libs/db ? Doesn't matter in this context since somebody just wanted examples. > > > dev-libs/boost > > Has one unmasked slot in-tree Oh, you got me. Nevertheless, will be 4 by the end of the week. > > > dev-lang/python > > > > So, wait, you want to depend on specific slots of python and keep them > around, and manage all their related bugs? Isn't that exactly the > opposite of what python upstream suggests, and *ALL* distros do? See dleverton's reply. > > > Besides: We wouldn't need the need_python_rebuild anymore, users could > > safely uninstall old sys-libs/db versions, old dev-libs/boost versions > > @preserved-libs. More generic, a low-level catch-all for library > breakages, and more convenient for users (rebuild as and when > possible, not *right now* lest everything break). > > > and the list of packages to reinstall in python-updater boils down to > > what "paludis -u dev-lang/python:2.4" spits out as reverse-dependencies > > (or the corresponding portage command). > > You mean emerge -C dev-lang/python:2.4 ? That'll say "bai bai python". > In any case, what is wrong with python_need_rebuild ? > > Slot operators need changes to the ebuilds, so does python_need_rebuild. > Slot operators need an EAPI bump for the ebuild, python_need_rebuild doesn't. > > So, isn't python_need_rebuild superior.. ? > No. Python rebuild makes explicit use of how vdb works. Which is not specified by eapi and therefore not guaranteed to work. But since you checked how things work before you start writing you already know that, don't you? signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[gentoo-dev] Re: EAPI-3 draft: slot operator support
Nirbheek Chauhan posted 8b4c83ad0904091106w1dd21b30v8d98c528d02de...@mail.gmail.com, excerpted below, on Thu, 09 Apr 2009 23:36:16 +0530: > On Thu, Apr 9, 2009 at 10:15 PM, Tiziano Müller > wrote: >> roughly 90% packages depending on one of: >> >> sys-libs/db > > Why the hell does this have so many slots in-tree? I am unaware of the > reasons for it. Horribly changed API every release? How does every other > distro handle sys-libs/db ? Yes, they specifically don't maintain API thru minor version numbers (tho AFAIK they do for micro, third field). Most other distributions are binary and release only periodically, not the "rolling update" Gentoo does, so they can declare a target db version for a release and build everything to it. >> Besides: We wouldn't need the need_python_rebuild anymore, users could >> safely uninstall old sys-libs/db versions, old dev-libs/boost versions > > @preserved-libs. More generic, a low-level catch-all for library > breakages, and more convenient for users (rebuild as and when possible, > not *right now* lest everything break). Honestly I'm wondering if that's going to end up a "failed experiment" much like confcache. Many of us users anyway running portage 2.2 turned off that feature right away, as it was breaking more stuff than it fixed. OTOH, since I turned it off as too much trouble for the small gain, I've not been tracking it so closely. Maybe the bugs are all pretty much resolved... But it's not something I expect to be turning on again right away. Once burned twice shy, and all that... tho I admit I'd value it much higher if my system was on the slow side instead of the fast side. And as a ~arch user that often answers questions stable users have that I dealt with six months or whatever ago, I'm not especially optimistic that /I'm/ not going to be seeing bugs based on it. That being the case, I can only imagine the headache it would threaten were I a bug wrangler or package maintainer actually having to deal with those bugzilla entries. Like I said, I have visions of confcache just thinking about it. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] One-Day Gentoo Council Reminder for April
On 16:36 Wed 08 Apr , Rémi Cardona wrote: > Mike Frysinger a écrit : >> This is your one-day friendly reminder ! The monthly Gentoo Council >> meeting is tomorrow in #gentoo-council on irc.freenode.net. See the >> channel topic for the exact time (but it's probably 2000 UTC). > > I'd like for the Council to discuss a migration plan from old > default-linux/ profiles to the new directory hierarchy. > > Adding arch-wide package.masks (we had to for Gnome 2.24 IIRC) was a > major pain for those who had to do it. > > I don't particularly wish for this to happen Real Soon, but drafting a > plan sounds like a good first step. OK, I'm looking forward to reading your draft. =) -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpifs1GWOZju.pgp Description: PGP signature
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thursday 09 April 2009 19:06:16 Nirbheek Chauhan wrote: > > dev-lang/python > > So, wait, you want to depend on specific slots of python and keep them > around, and manage all their related bugs? Isn't that exactly the > opposite of what python upstream suggests, and *ALL* distros do? If you install a Python library for Python x.y, even if the library itself can support other versions, then the installed package depends on Python x.y, period. Using := is simply acknowledging that fact. It doesn't mean you have to keep x.y around for all time, but it does mean that the package manager knows what needs to be reinstalled before x.y can safely be removed. > @preserved-libs. More generic, a low-level catch-all for library > breakages, and more convenient for users (rebuild as and when > possible, not *right now* lest everything break). More generic? @preserved-libs knows about Python now? And the whole point of slotting is that you can keep old versions installed, so you don't need to rebuild dependent packages "right now".
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thu, Apr 9, 2009 at 10:15 PM, Tiziano Müller wrote: > roughly 90% packages depending on one of: > > sys-libs/db Why the hell does this have so many slots in-tree? I am unaware of the reasons for it. Horribly changed API every release? How does every other distro handle sys-libs/db ? > dev-libs/boost Has one unmasked slot in-tree > dev-lang/python > So, wait, you want to depend on specific slots of python and keep them around, and manage all their related bugs? Isn't that exactly the opposite of what python upstream suggests, and *ALL* distros do? > Besides: We wouldn't need the need_python_rebuild anymore, users could > safely uninstall old sys-libs/db versions, old dev-libs/boost versions @preserved-libs. More generic, a low-level catch-all for library breakages, and more convenient for users (rebuild as and when possible, not *right now* lest everything break). > and the list of packages to reinstall in python-updater boils down to > what "paludis -u dev-lang/python:2.4" spits out as reverse-dependencies > (or the corresponding portage command). You mean emerge -C dev-lang/python:2.4 ? That'll say "bai bai python". In any case, what is wrong with python_need_rebuild ? Slot operators need changes to the ebuilds, so does python_need_rebuild. Slot operators need an EAPI bump for the ebuild, python_need_rebuild doesn't. So, isn't python_need_rebuild superior.. ? -- ~Nirbheek Chauhan
Re: [gentoo-dev] net-www category
> On Sun, 5 Apr 2009, I wrote: >> Since most of the stuff in net-www seems to be browser plugins, >> we could create www-plugins. > Is the following a reasonable scheme? > [...] Looks like there are no objections against it, so I've created the www-plugins category. Migration of packages is tracked in bug 265569. Ulrich
Re: [gentoo-dev] EAPI 3 PMS Draft
Ciaran McCreesh wrote: Most packages that have tests have working tests. For those that don't, the tests have to be restricted. All this proposal does is ensures that that happens in a progressive, incremental and safe way. I agree with this point - failing tests are more the exception than the rule. Looking at my system the only packages I'm skipping tests for are: openldap|parted|orbit|samba|kpilot|nautilus|libksieve|karm|libbonoboui|gnome-vfs|pkgconfig|pam|coreutils|pan|mono|glibc|gettext|curl Some of those might be fixed now. If packages are failing tests, either it's a legitimate reason, in which case it needs to be fixed, or it's not, in which case it needs to be restricted. The problem is, currently there's no way for users to know which is which. With an EAPI mandated src_test, users will know that any failure that gets to them is legitimate. Hence my having the list posted above (which is just the ones I use that I've found problems with). I also would like to say that the "slow-test" compromise sounds like a good idea. A fast-running automated test routine is a good sanity check to show that nothing went wrong during the build. Maybe the user has some odd version of a dependency that no developer checked with the new package. Arch testers can't test every combination of dependencies, configurations, use-flags, etc. I would think that this might even cut down on user-reported issues. Better to find out that a package has a problem BEFORE it is actually installed. If a user is going to spend 10 minutes building a bunch of packages spending another 30-60 seconds on some basic tests doesn't sound unreasonable. We could also make it easy for users to disable testing entirely if they want to live dangerously.
Re: [gentoo-dev] EAPI-3 draft: slot operator support
Am Donnerstag, den 09.04.2009, 12:03 +0200 schrieb Rémi Cardona: > Mart Raudsepp a écrit : > > Hello, > > > > > > This thread is for any discussion about the slot operator support item > > in EAPI-3 draft. > > Could anyone actually give a good reason for slot operators? What > packages would have a _clear_ benefit from using them? I'm asking for an > actual list of packages, not just some package that may exist in a > parallel universe. roughly 90% packages depending on one of: sys-libs/db dev-libs/boost dev-lang/python Sooo, something around 500 packages. Besides: We wouldn't need the need_python_rebuild anymore, users could safely uninstall old sys-libs/db versions, old dev-libs/boost versions and the list of packages to reinstall in python-updater boils down to what "paludis -u dev-lang/python:2.4" spits out as reverse-dependencies (or the corresponding portage command). signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] EAPI 3 PMS Draft
On Thu, 9 Apr 2009 18:21:55 +0200 Patrick Lauer wrote: > > Which is why we are not talking about enabling it for the tree. We > > are talking about enabling it for a subset of the tree that's > > guaranteed to have been tested by it. > > So you propose to make a new EAPI that about 2.5% of the tree can use? Of course not. No-one's stupid enough to think that's even remotely true, so please don't say things like that. Most packages that have tests have working tests. For those that don't, the tests have to be restricted. All this proposal does is ensures that that happens in a progressive, incremental and safe way. Had src_test been introduced after EAPIs came along, this would already have happened. > And it is still the same stupid idea. We have FEATURES="test" for > those who care, and if you look at the amount of bugs that causes > already I see no sane way to make it default. It causes lots of bugs because it's not the default. > Why would you enable it by default just to disable it by default in > those packages where it is the most important? If packages are failing tests, either it's a legitimate reason, in which case it needs to be fixed, or it's not, in which case it needs to be restricted. The problem is, currently there's no way for users to know which is which. With an EAPI mandated src_test, users will know that any failure that gets to them is legitimate. > Tell you what. Provide patches for all open test failure bugs and > provide a list of all packages where tests are slow (for certain > values of slow we'd have to agree on) and you can resume pushing your > toy ideas. There's no need to. That's the beauty of this proposal. As packages are moved to EAPI 3, any package with broken tests can, at the maintainer's choice, either get RESTRICT=test (which they should have been given already) or get fixed tests. This is no more work for maintainers. All it does is makes sure they do something they should be doing already, and in the process makes things much safer for users. Again, this has all already been covered. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 3 PMS Draft
On Thu, 09 Apr 2009 19:20:39 +0300 Mart Raudsepp wrote: > Every single test on any package is going to be done slower than not > running tests. So? If speed were important, people would use a binary distribution, or just drop to -O1. But given the massive variability of Gentoo systems, correctness is a far bigger worry. > This PROPERTIES proposal has no relevance to the argument of why it is > an extremely bad idea to enable it by default. Sure it does. It means that for any package where there's a really large slow-down, users will only run the tests if they want to. > > We've been over all of this several times previously. > > Yes, and by my understanding this will not be happening anytime soon, > if ever, so I can repeat all my sound objections to it whenever you > bring it up again in the more distant future, thank you. Unfortunately, it looks like this proposal's one of those things that some people will hate for ideological reasons no matter what. I just hope there're enough people on the Council for whom QA and user systems not breaking is sufficiently important that they'll vote in favour of it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 3 PMS Draft
On Thursday 09 April 2009 16:37:55 Ciaran McCreesh wrote: > On Thu, 09 Apr 2009 04:12:02 +0300 > > Mart Raudsepp wrote: > > It is quite irresponsible to enable that by default for the FULL user > > base, given the state of the tree in regards to it > > Which is why we are not talking about enabling it for the tree. We are > talking about enabling it for a subset of the tree that's guaranteed to > have been tested by it. So you propose to make a new EAPI that about 2.5% of the tree can use? > > and the (very) considerable extra time it takes to run them while > > it's already slower in relation to binary distributions. > > PROPERTIES="slow-tests" then. > > We've been over all of this several times previously. And it is still the same stupid idea. We have FEATURES="test" for those who care, and if you look at the amount of bugs that causes already I see no sane way to make it default. Why would you enable it by default just to disable it by default in those packages where it is the most important? Tell you what. Provide patches for all open test failure bugs and provide a list of all packages where tests are slow (for certain values of slow we'd have to agree on) and you can resume pushing your toy ideas. Have fun, Patrick
Re: [gentoo-dev] EAPI 3 PMS Draft
On N, 2009-04-09 at 15:37 +0100, Ciaran McCreesh wrote: > On Thu, 09 Apr 2009 04:12:02 +0300 > Mart Raudsepp wrote: > > It is quite irresponsible to enable that by default for the FULL user > > base, given the state of the tree in regards to it > > Which is why we are not talking about enabling it for the tree. We are > talking about enabling it for a subset of the tree that's guaranteed to > have been tested by it. > > > many upstreams stance on tests and their failures > > So for those packages, RESTRICT tests like you should be doing anyway. > > > and the (very) considerable extra time it takes to run them while > > it's already slower in relation to binary distributions. > > PROPERTIES="slow-tests" then. Every single test on any package is going to be done slower than not running tests. This PROPERTIES proposal has no relevance to the argument of why it is an extremely bad idea to enable it by default. All developers should enable it (a QA enforcement), but users by default - no, NO. There is more to a distribution than technical considerations. > We've been over all of this several times previously. Yes, and by my understanding this will not be happening anytime soon, if ever, so I can repeat all my sound objections to it whenever you bring it up again in the more distant future, thank you. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 3 PMS Draft
On Thu, 09 Apr 2009 04:12:02 +0300 Mart Raudsepp wrote: > It is quite irresponsible to enable that by default for the FULL user > base, given the state of the tree in regards to it Which is why we are not talking about enabling it for the tree. We are talking about enabling it for a subset of the tree that's guaranteed to have been tested by it. > many upstreams stance on tests and their failures So for those packages, RESTRICT tests like you should be doing anyway. > and the (very) considerable extra time it takes to run them while > it's already slower in relation to binary distributions. PROPERTIES="slow-tests" then. We've been over all of this several times previously. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Thu, 09 Apr 2009 13:44:55 +0300 Mart Raudsepp wrote: > But the metadata cache isn't per-EAPI in the sense of multiple > metadata caches, one for each EAPI. There might be per-EAPI metadata > cache items though. The cache format is per-EAPI, with a degree of overlap. > I don't think I want to have to specify userland_GNU and co in IUSE. > They aren't USE flags that get set by the user, so having to put them > in IUSE isn't intuitive either. And with the proposal as currently worded, you don't have to. The profiles do that magically for you. > Some might accept all current switches we pass with econf, but not > --disable-dependency-tracking. 'might'? Have you found any? Given the mess econf currently passes, it strikes me as highly unlikely. > Then we should disallow all constructs that currently give a repoman > warning as well? We should disallow constructs that can't be used correctly, if allowing them is a significant burden on the package manager. > Unknown types in this case is about "not packed at all". > Or we could define those types - .patch, .bin, etc > PM knows that there's .lzma, .xz and so on, so it could know which > build-time deps are necessary - repoman warning anyhow, later some > alternative unpacker might surface. Uh. Unknown types doesn't mean "fail on lzma if lzma's not installed". Please check the PMS draft for what it does mean. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Thu, 09 Apr 2009 04:51:06 +0300 Mart Raudsepp wrote: > doins support for symlinks > == > > Lacking information. Need to see if the PMS draft has anything about > it. The bug and summaries just talk about the support, but no > details. Would it be an argument to doins? The PMS draft explains it. It's simple, though: currently, doins on a symlink does something arbitrary. We want it to install the symlink. > unpack failing on unknown types > === > > Uncertain about it's worthiness. Might rather have the opposite with a > --strict argument kind of deal. No official objection from me. What with the moving towards auto-die, the trend is towards "strict unless explicitly told not to be". > properties must be cached properly > == > > No opinion, up to the package manager developers. > Don't see offhand why it should be an EAPI item at all. Feels like an > implementation detail. The cache format's tied to EAPI in a fairly unpleasant manner. It's a necessary evil. > DEFINED_PHASES must be supported (and cached properly) > == > > No opinion, up to the package manager developers more or less. > Not sure why this needs to be an EAPI item. Hard to see a use case for > the variable being available for ebuild usage for it to be necessary > to be an EAPI item. DEFINED_PHASES isn't available to the ebuild. But it is in the metadata cache, which PMS has to cover. > By my understanding it is (also?) a required implementation detail to > handle pkg_pretend sanely and with minimal time hit. Correct. Without it there's a delay of ~0.1s per ebuild in the resolution set at pretend time, which soon adds up for certain reasonably common use cases. > Limit values in $USE to ones in $IUSE: > == > > Seems more of a QA test, but forcing it can make it be caught at > start. Don't see why it must be an EAPI item. Just vet the tree of > (future?) repoman warnings about it and make it happen for > all EAPIs. Impact on overlays is minimal because it is a QA error to > not define them and they get what they asked for. It needs to be in EAPI because we're talking about changing how the ebuild environment is specified. Also, repoman can't catch most accidental abuses of this. > --disable-dependency-tracking: > == > > possible breakage of (custom) configure scripts that don't accept > unknown arguments. Would be nice to pass that for most packages, but > doing it always with econf seems slightly inappropriate, given the > above. Please provide a list of packages that use custom configure scripts, that currently work with econf (including all the weird things it already passes), that would break with this change and whose ebuilds are using econf. I have yet to see any examples provided. > utility commands should die by default > == > > Would like to see a list of those utility commands that would be made > to die by default. The PMS draft has one. > ban || ( foo? ( . ) . ) > === > > It is not the business of an EAPI to start disallowing *DEPEND string > constructs. > There is no useful alternative provided yet to my knowledge and this > is really a QA issue, not an EAPI issue. There is no use case for the construct anyway. > Not convinced on the sub-optimal use case being the only one, either. > > Strongly objecting on the grounds that it is not something that should > be an EAPI issue. Behaviour of || ( foo? ( . ) ) is already an EAPI issue, and has a horrible section of PMS devoted to explaining its quirky behaviour. > I'm not even sure anymore where to find a list of items that is > current for what's on the table for EAPI-3 right now... Do a git log on the PMS draft (or look at the summary table in the appendix). It's fairly close to one commit per EAPI item. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thu, 09 Apr 2009 05:25:33 +0300 Mart Raudsepp wrote: > Are we sure := and :* is the syntax that makes sense once we try to > cover some of the above with new syntax? := and :* covers the cases that can be covered with existing dependency ranges. If you want to cover things that need horrible || hacks with the current dependency format, you also need either to add ||= and ||* dependencies (which run against the definition of ||) or start supporting [>=2&<3] ranged dependencies. := and :* are appropriate. Your objections to them are based upon limitations with the current dependency format, and have nothing to do with := and :* themselves. They're not real limitations, either, since as Tiziano points out, in the real world there's a neat correspondence between version ranges and slots, and if there aren't you can't deal with them anyway. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thu, 9 Apr 2009 17:06:47 +0530 Nirbheek Chauhan wrote: > So you're looking for ABI deps? @preserved-libs is the answer (C-sharp > support for that?). Suggested rebuilds upon upgrade? Separate issue, > separate solution (pkg_pretend maybe?) @preserved-libs is a horrible hack that is used in place of ABI deps. It requires a seperate implementation for each language/subset of packages and does not take into account "silent" ABI breakage. *DO*NOT*WANT* In other words. :-)
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thu, Apr 9, 2009 at 4:56 PM, Peter Alfredsen wrote: > As I said, I would be using slot-deps as ABI-deps. I would find actual > ABI deps to be vastly more useful since I wouldn't have to keep track > of earlier slots to block. > > Imagine a world with no revdep-rebuild? > So you're looking for ABI deps? @preserved-libs is the answer (C-sharp support for that?). Suggested rebuilds upon upgrade? Separate issue, separate solution (pkg_pretend maybe?) -- ~Nirbheek Chauhan
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thu, 9 Apr 2009 16:29:53 +0530 Nirbheek Chauhan wrote: > I think the current way is the most easily-supportable way for us. > Complex interdependencies b/w packages and slots => O(n^k) times bugs, > where k = no. of slots for a library. > > If we don't get all those bugs, it means people are running the latest > package and latest slot. So slot operators would be m00t in that case. I wouldn't be using slotdeps as actual slotdeps, more like ABI deps. Each slot would soft-block all other slots, so upgrades would be handled normally by portage. Only, all other packages could use slotdeps to be rebuilt when a new version of gtk-sharp is released. It would probably take a bit of eclass fudgery, but it could be made to work. Also, it would allow people to mix ~arch and arch for -sharp stuff. Which would be good. As I said, I would be using slot-deps as ABI-deps. I would find actual ABI deps to be vastly more useful since I wouldn't have to keep track of earlier slots to block. Imagine a world with no revdep-rebuild? /loki_val
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On N, 2009-04-09 at 11:30 +0200, Tiziano Müller wrote:
> Am Donnerstag, den 09.04.2009, 05:25 +0300 schrieb Mart Raudsepp:
> > Hello,
> >
> >
> > This thread is for any discussion about the slot operator support item
> > in EAPI-3 draft.
> >
> > The premise is good what := and :* allow for, but I'm concerned about
> > the syntax possibly ending up being suboptimal in relation to the syntax
> > we come up in the future for covering the cases not covered now.
> >
> >
> > Such cases are for example:
> >
> > * A library package has slots 2.4, 2.6 and 2.8. An application works
> > with either 2.6 or 2.8, but needs a recompile for changed ABI. It does
> > not work with 2.4 - it has API missing that it needs.
> DEPEND=RDEPEND=">=cat/lib-2.6:="
This is an abuse of the version number. There is no actual guarantee
that SLOT 2.6 revisions carry a 2.6* version number, etc.
> > * Same case as previous, but additionally the library has a version with
> > slot 3.0 - it is a complete redesign and applications working with 2.8
> > have no chance of working. So need to express a list of acceptable SLOTs
> > or a minimum and maximum (but slots aren't really guaranteed to be
> > numeric and versionable).
> slot operators won't help here, so it remains:
> RDEPEND="|| ( cat/lib:2.6 cat/lib:2.8 )"
The package additionally needs to know which one the package manager
picked for it, to instruct the build system to actually use that
version.
Without this the whole := deal is pretty useless for many cases.
> with ranged dependencies:
> RDEPEND="cat/lib[>=2.6&<3]:="
Version/slot mixing abuse
> or slot ranges:
> RDEPEND="cat/lib:[2.6|2.8]="
> or
> RDEPEND="cat/lib:=[2.6|2.8]"
> (depends on how we want to define the syntax)
I guess that would go along with the := proposed now and therefore be an
evolution and not a problem to do := now. At least for this case.
> > * Same case as previous (either of them), but if using SLOT 2.6, it
> > needs to be at least >=libr/ary-2.6.5:2.6 and if SLOT 2.8 at least
> > >=libr/ary-2.8.3:2.8. A re-compile if switching provider may or may not
> > be necessary (considering both cases separately)
> slot operators won't help here, so it remains:
> RDEPEND="|| ( >=cat/lib-2.8.3:2.8 >=cat/lib-2.6.5:2.6 )"
That doesn't work for the same reason cat/lib or || ( cat/lib:2.6
cat/lib:2.8 ) doesn't.
> again with ranged dependencies (somebody please check this):
> RDEPEND="cat/lib[<3.0&(>=2.8.3|>=2.6.5)]:="
> or
> RDEPEND="cat/lib[<3.0&(>=2.8.3|>=2.6.5)]:*"
>
> or maybe combined with slot ranges:
> RDEPEND="cat/lib[>=2.8.3|>=2.6.5]:=[2.8|2.6]
There is no relation between 2.8.3 and slot 2.8 here really.
We do not declare anywhere how SLOT naming related to version numbers
it's used in. So none of those examples work for me.
> please note: the ebuild maintainer has to make sure that the package has
> to use the best-matching version, otherwise even the slot specifiers are
> worthless.
The package manager needs to tell the ebuild which version it went with,
or this doesn't work right. If you assume best matching version always,
then all this slot operator deal becomes superfluous. Maintainers should
then simply always depend on just the latest version and there is
minimal benefits to slot operators and the complexity in the readability
might not be worth it.
> Real-world example for that:
> DEPEND="sys-libs/db:="
> RDEPEND="${RDEPEND}"
>
> By the time of installation you have sys-libs/db:{4.6,4.7} installed,
> then your app has to use sys-libs/db:4.7.
> (best_version should provide that information as far as I know).
>
> >
> > * A library provides slots 1.2, 1.4 and 1.6. An application can work
> > with all of them, but needs a recompile if upgrading from being linked
> > against 1.2 to newer. 1.4 and 1.6 are runtime interchangeable. Very rare
> > possibility of this though, involving dlopen and more. Probably
> > acceptable to declare rebuild need for all changes.
> Yes.
>
> > Are we sure := and :* is the syntax that makes sense once we try to
> > cover some of the above with new syntax?
> Yes. It's quiet extendable (as seen above).
>
> >
> > Perhaps some forward thinking is sensible here to not end up with having
> > to deprecate the := and :* syntax soon after its introduction.
> Done.
I see no need for :* based on the examples provided and can't think of
any real world cases for it either right now.
There is that theoretical case when some package does dynamic usage of
the library through dlopen and handles the ABI differences, but even
then there is no guarantee (and it is quite unlikely) that it can handle
a future ABI SLOT of the library, and so using :* is unsafe, and :=[list
of known to work ABI SLOTs] should be used instead.
--
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thu, Apr 9, 2009 at 4:09 PM, Peter Alfredsen wrote: > All package depending on dev-dotnet/gtk-sharp. Although these won't be > parallel-installable slots, it will really easy the transition between > versions and allow us to ease the currently quite strict > interdependencies between the various packages that make up the > gtk-sharp, gnome-sharp and gnome-desktop-sharp tarballs, where all > versions of all packages are bound to a single gtk-sharp major version > (2.12 at the moment). Currently we handle bumps in api by bumping every > package in this trifecta from hell. That way, users only have to > rebuild their apps, portage will take care of rebuilding the -sharp > libs. > I think the current way is the most easily-supportable way for us. Complex interdependencies b/w packages and slots => O(n^k) times bugs, where k = no. of slots for a library. If we don't get all those bugs, it means people are running the latest package and latest slot. So slot operators would be m00t in that case. -- ~Nirbheek Chauhan
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On N, 2009-04-09 at 10:37 +0200, Tiziano Müller wrote: > > properties must be cached properly > > == > > > > No opinion, up to the package manager developers. > > Don't see offhand why it should be an EAPI item at all. Feels like > an > > implementation detail. > > The metadata cache needs to be specified to make it work with > compliant > PM's and is therefore a part of the PMS. > A change is therefore required to be done on a per-EAPI base. But the metadata cache isn't per-EAPI in the sense of multiple metadata caches, one for each EAPI. There might be per-EAPI metadata cache items though. Anyhow, if zmedico is cool with it, I'm cool. > > Limit values in $USE to ones in $IUSE: > > == > > > > Seems more of a QA test, but forcing it can make it be caught at > start. > > Don't see why it must be an EAPI item. Just vet the tree of > (future?) > > repoman warnings about it and make it happen for > > all EAPIs. Impact on overlays is minimal because it is a QA error to > not > > define them and they get what they asked for. > > > > Not strongly opposed to it being in the EAPI. > > > Why it has to be done in an EAPI: It matters whether you have to put > for > example userland_GNU in IUSE if you want to use it in the ebuild or > not. I don't think I want to have to specify userland_GNU and co in IUSE. They aren't USE flags that get set by the user, so having to put them in IUSE isn't intuitive either. > > > > > --disable-dependency-tracking: > > == > > > > possible breakage of (custom) configure scripts that don't accept > > unknown arguments. Would be nice to pass that for most packages, but > > doing it always with econf seems slightly inappropriate, given the > > above. > > Don't think this is an item for fast-tracked EAPI-3. > > custom configure scripts mostly already break with econf, so not an > issue. Some might accept all current switches we pass with econf, but not --disable-dependency-tracking. Maybe if there's a way to opt out of the --disable-dependency-tracking when necessary... the unlikely need for that will get seen by the maintainer when he/she upgrades the ebuild to EAPI-3. econf is a complex and long (many arguments passed) beast to replicate just without --disable-dependency-tracking > > ban || ( foo? ( . ) . ) > > === > > > > It is not the business of an EAPI to start disallowing *DEPEND > string > > constructs. > It's EAPI's business to define what's valid and what is not. We disagree there. Things should be an EAPI item when it is reasonably required to be. In this case a simple repoman warning on such a construct suffices. > > There is no useful alternative provided yet to my knowledge and this > is > > really a QA issue, not an EAPI issue. > The problem is that there is no valid use case to justify the > existence > of this construct. In either way users will most likely not have what > they want if "|| ( foo? ( . ) . )" is being used. Disallowing it will > therefore help the user to get what the specified and is therefore a > good thing. Then we should disallow all constructs that currently give a repoman warning as well? It is a QA issue to me, not something to overload an EAPI with. QA warning for all EAPI's. > > Not convinced on the sub-optimal use case being the only one, > either. > > > > Strongly objecting on the grounds that it is not something that > should > > be an EAPI issue. > > > > > > unpack has to handle more types > > === > > > > Would be nice to get a QA warning when unpacking .lzma, .xz, etc > that > > need a build depend for the unpacker and don't have it yet. Then > sounds > > fine. > But you don't want unpack fail on unknown types? Seems a bit > inconsequent. Unknown types in this case is about "not packed at all". Or we could define those types - .patch, .bin, etc PM knows that there's .lzma, .xz and so on, so it could know which build-time deps are necessary - repoman warning anyhow, later some alternative unpacker might surface. > > Did I miss anything? > > I'm not even sure anymore where to find a list of items that is > current > > for what's on the table for EAPI-3 right now... > > > The PMS. (just do "emerge pms" for an up-to-date version). that's a bit complicated with not having texlive installed anywhere yet... -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thu, 09 Apr 2009 12:03:03 +0200 Rémi Cardona wrote: > Could anyone actually give a good reason for slot operators? What > packages would have a _clear_ benefit from using them? I'm asking for > an actual list of packages, not just some package that may exist in a > parallel universe. All package depending on dev-dotnet/gtk-sharp. Although these won't be parallel-installable slots, it will really easy the transition between versions and allow us to ease the currently quite strict interdependencies between the various packages that make up the gtk-sharp, gnome-sharp and gnome-desktop-sharp tarballs, where all versions of all packages are bound to a single gtk-sharp major version (2.12 at the moment). Currently we handle bumps in api by bumping every package in this trifecta from hell. That way, users only have to rebuild their apps, portage will take care of rebuilding the -sharp libs.
[gentoo-dev] Default XDG env.d configuration placement
Hi guys (and lads), we have this nice shiny bug [1] where we discuss how to best add the env.d file with default XDG configuration. Description why it is needed so much is written in the bug itself so i wont duplicate the effort to write it here again :] So what do we need from you. :] Actualy quite simple, where do you think it should belong. Some new fake package or added as part of some other package (currently the candidate is xdg-utils)... [1] - http://bugs.gentoo.org/show_bug.cgi?id=264647 Cheers Tomáš Chvátal Gentoo Linux Developer [KDE/Sunrise/X11] E-Mail : scarab...@gentoo.org GnuPG FP: 94A4 5CCD 85D3 DE24 FE99 F924 1C1E 9CDE 0341 4587 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI-3 draft: slot operator support
Mart Raudsepp a écrit : Hello, This thread is for any discussion about the slot operator support item in EAPI-3 draft. Could anyone actually give a good reason for slot operators? What packages would have a _clear_ benefit from using them? I'm asking for an actual list of packages, not just some package that may exist in a parallel universe. To me it just looks like it's overly complicated and it makes my eyes bleed. Rémi
Re: [gentoo-dev] EAPI-3 draft: slot operator support
Am Donnerstag, den 09.04.2009, 05:25 +0300 schrieb Mart Raudsepp:
> Hello,
>
>
> This thread is for any discussion about the slot operator support item
> in EAPI-3 draft.
>
> The premise is good what := and :* allow for, but I'm concerned about
> the syntax possibly ending up being suboptimal in relation to the syntax
> we come up in the future for covering the cases not covered now.
>
>
> Such cases are for example:
>
> * A library package has slots 2.4, 2.6 and 2.8. An application works
> with either 2.6 or 2.8, but needs a recompile for changed ABI. It does
> not work with 2.4 - it has API missing that it needs.
DEPEND=RDEPEND=">=cat/lib-2.6:="
> * Same case as previous, but additionally the library has a version with
> slot 3.0 - it is a complete redesign and applications working with 2.8
> have no chance of working. So need to express a list of acceptable SLOTs
> or a minimum and maximum (but slots aren't really guaranteed to be
> numeric and versionable).
slot operators won't help here, so it remains:
RDEPEND="|| ( cat/lib:2.6 cat/lib:2.8 )"
with ranged dependencies:
RDEPEND="cat/lib[>=2.6&<3]:="
or slot ranges:
RDEPEND="cat/lib:[2.6|2.8]="
or
RDEPEND="cat/lib:=[2.6|2.8]"
(depends on how we want to define the syntax)
> * Same case as previous (either of them), but if using SLOT 2.6, it
> needs to be at least >=libr/ary-2.6.5:2.6 and if SLOT 2.8 at least
> >=libr/ary-2.8.3:2.8. A re-compile if switching provider may or may not
> be necessary (considering both cases separately)
slot operators won't help here, so it remains:
RDEPEND="|| ( >=cat/lib-2.8.3:2.8 >=cat/lib-2.6.5:2.6 )"
again with ranged dependencies (somebody please check this):
RDEPEND="cat/lib[<3.0&(>=2.8.3|>=2.6.5)]:="
or
RDEPEND="cat/lib[<3.0&(>=2.8.3|>=2.6.5)]:*"
or maybe combined with slot ranges:
RDEPEND="cat/lib[>=2.8.3|>=2.6.5]:=[2.8|2.6]
please note: the ebuild maintainer has to make sure that the package has
to use the best-matching version, otherwise even the slot specifiers are
worthless.
Real-world example for that:
DEPEND="sys-libs/db:="
RDEPEND="${RDEPEND}"
By the time of installation you have sys-libs/db:{4.6,4.7} installed,
then your app has to use sys-libs/db:4.7.
(best_version should provide that information as far as I know).
>
> * A library provides slots 1.2, 1.4 and 1.6. An application can work
> with all of them, but needs a recompile if upgrading from being linked
> against 1.2 to newer. 1.4 and 1.6 are runtime interchangeable. Very rare
> possibility of this though, involving dlopen and more. Probably
> acceptable to declare rebuild need for all changes.
Yes.
> Are we sure := and :* is the syntax that makes sense once we try to
> cover some of the above with new syntax?
Yes. It's quiet extendable (as seen above).
>
> Perhaps some forward thinking is sensible here to not end up with having
> to deprecate the := and :* syntax soon after its introduction.
Done.
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Donnerstag, den 09.04.2009, 04:51 +0300 schrieb Mart Raudsepp: > Hello, > > On Sun, 2009-03-08 at 08:49 +0100, Tiziano Müller wrote: > > > With eapis 1 and 2 we introduced nice features but also a couple of > > new > > problems. One of them are the use dependencies when the package you > > depend on doesn't have the use flag anymore (see [1] for an example). > > > > So I think it's time for a short eapi bump with some distinct > > improvements: > > > > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ > > > > > > Please discuss. > > > Sorry for getting my points of discussion on the details to the list so > late. > I have covered some of my concerns on the items in meetings and > otherwise on IRC, but now I'll try to get to them in further detail and > better wording to the mailing list. > > I'm going to go item-by-item here for the things I don't expect much > replies to, and then starting separate threads for those that I do. > > > pkg_pretend > === > > No objections. > Gives an intermediate step for handling USE flag combination > incompatibilities at pretend stage (to not find it failed in the > morning), yet has uses outside that as well. So, once there is a way to > express those kind of USE flag dependencies outside of pkg_pretend in a > better way in a future EAPI, pkg_pretend will still be useful for other > (less common) cases and can provide a description of the problem to the > user. > > > Use based deps with non-existing USE flags > == > > No objections. > Implements the missing bit of "built_with_use --missing" > Main driving force behind EAPI-3. > > > default src_install > === > > No considerable input yet, catching up with the latest thread about > src_install bikeshedding > > > doinclude > = > > Unnecessary. Might be interesting for automatic executable permission > removing, but upstream build systems should be fixed instead for such a > big and rare error. > > > ban dosed > = > > I don't exactly see a reason for the banning yet, but no objections due > to general agreement on it and having no technical objections > > > doins support for symlinks > == > > Lacking information. Need to see if the PMS draft has anything about it. > The bug and summaries just talk about the support, but no details. Would > it be an argument to doins? > > > unpack failing on unknown types > === > > Uncertain about it's worthiness. Might rather have the opposite with a > --strict argument kind of deal. No official objection from me. > > > docompress > == > > Need some more time to digest through it in relation to > PORTAGE_COMPRESS, prepalldocs and co. Will try to follow-up before > meeting. > > > properties must be cached properly > == > > No opinion, up to the package manager developers. > Don't see offhand why it should be an EAPI item at all. Feels like an > implementation detail. The metadata cache needs to be specified to make it work with compliant PM's and is therefore a part of the PMS. A change is therefore required to be done on a per-EAPI base. > > > DEFINED_PHASES must be supported (and cached properly) > == > > No opinion, up to the package manager developers more or less. > Not sure why this needs to be an EAPI item. Hard to see a use case for > the variable being available for ebuild usage for it to be necessary to > be an EAPI item. > By my understanding it is (also?) a required implementation detail to > handle pkg_pretend sanely and with minimal time hit. > > > Limit values in $USE to ones in $IUSE: > == > > Seems more of a QA test, but forcing it can make it be caught at start. > Don't see why it must be an EAPI item. Just vet the tree of (future?) > repoman warnings about it and make it happen for > all EAPIs. Impact on overlays is minimal because it is a QA error to not > define them and they get what they asked for. > > Not strongly opposed to it being in the EAPI. > Why it has to be done in an EAPI: It matters whether you have to put for example userland_GNU in IUSE if you want to use it in the ebuild or not. > > --disable-dependency-tracking: > == > > possible breakage of (custom) configure scripts that don't accept > unknown arguments. Would be nice to pass that for most packages, but > doing it always with econf seems slightly inappropriate, given the > above. > Don't think this is an item for fast-tracked EAPI-3. custom configure scripts mostly already break with econf, so not an issue. > > > utility commands should die by default > == > > Would like to see a list of those utility commands that would be made to > die by default. basically all do* commands. > > > ban || ( foo? ( . ) . ) > =
