Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 2012-06-20 at 17:50 +0100, Ciaran McCreesh wrote: Then there are ebuilds that don't call eautoreconf, in the first place. Should we require that all of them inherit autotools now, just for the unlikely case that user patches could be applied? If the aim is to provide a working feature to users, yes. The alternative is to not provide user patches support. Damnit, let the user shoot themself in the foot but let them learn from it. Remember back in the day when you had no clue? You learned from it. You can only protect them so much. If they want to use custom patches then they need to learn how. -- Homer Parker hpar...@gentoo.org signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About what would be included in EAPI5
On Thu, 21 Jun 2012 07:04:41 -0500 Homer Parker hpar...@gentoo.org wrote: Damnit, let the user shoot themself in the foot but let them learn from it. Remember back in the day when you had no clue? You learned from it. You can only protect them so much. If they want to use custom patches then they need to learn how. That's not the issue. The issue is advertising a user patches feature when there's no way for the user to know up-front whether or not their patches will be applied. This whole discussion started because user patches are currently randomly ignored sometimes. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Thu, 2012-06-21 at 13:25 +0100, Ciaran McCreesh wrote: On Thu, 21 Jun 2012 07:04:41 -0500 Homer Parker hpar...@gentoo.org wrote: Damnit, let the user shoot themself in the foot but let them learn from it. Remember back in the day when you had no clue? You learned from it. You can only protect them so much. If they want to use custom patches then they need to learn how. That's not the issue. The issue is advertising a user patches feature when there's no way for the user to know up-front whether or not their patches will be applied. This whole discussion started because user patches are currently randomly ignored sometimes. I guess I missed it's not a global feature, sorry. That said, everything else stands. -- Homer Parker hpar...@gentoo.org signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About what would be included in EAPI5
On Sat, 16 Jun 2012 14:12:13 +0200 Ulrich Mueller u...@gentoo.org wrote: On Sat, 16 Jun 2012, Pacho Ramos wrote: I would like to know if there is some place where things going to be included (or proposed to be included) for eapi5 are listed (if such place exists). Currently, looks like there is no eapi5 tracker :-/ The PMS git repository has an eapi-5 development branch, and some parallel discussion took place in the gentoo-pms mailing list. So far we have: ╓ ║ EAPI 5 is EAPI 4 with the following changes: ║ ║ • econf adds --disable-silent-rules. ║ • Slot operator dependencies. ║ • src_test supports parallel tests. ║ • USE is calculated differently. ║ • IMAGE is gone. ║ • REQUIRED_USE now supports ?? groups. ║ • apply_user_patches function, with src_prepare changes. ║ • EBUILD_PHASE_FUNC. ║ • find is guaranteed to be GNU. ║ • new* can read from standard input. ╙ Could someone open bugs for all of that? I was looking for user patches on the future EAPI tracker, and I don't see it there. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012 11:07:55 +0200 Michał Górny mgo...@gentoo.org wrote: Could someone open bugs for all of that? I was looking for user patches on the future EAPI tracker, and I don't see it there. Please don't. User patches were discussed on this list, and there's already wording written. We don't need a bug to track it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012 12:02:42 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 20 Jun 2012 11:07:55 +0200 Michał Górny mgo...@gentoo.org wrote: Could someone open bugs for all of that? I was looking for user patches on the future EAPI tracker, and I don't see it there. Please don't. User patches were discussed on this list, and there's already wording written. We don't need a bug to track it. So you want requests here or do I have do look back to find that thread? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012 13:12:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Wed, 20 Jun 2012 12:02:42 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Please don't. User patches were discussed on this list, and there's already wording written. We don't need a bug to track it. So you want requests here or do I have do look back to find that thread? I believe we consider the user patches feature to be finalised, so if you want something else, it should be treated as a new feature rather than a change. But please don't rehash anything that's already been covered. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012 12:14:38 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 20 Jun 2012 13:12:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Wed, 20 Jun 2012 12:02:42 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Please don't. User patches were discussed on this list, and there's already wording written. We don't need a bug to track it. So you want requests here or do I have do look back to find that thread? I believe we consider the user patches feature to be finalised, so if you want something else, it should be treated as a new feature rather than a change. But please don't rehash anything that's already been covered. I simply don't get why the spec obligates package managers to support user patches while it doesn't provide any explanation how the patches should be applied nor any function to actually apply patches... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012 13:22:22 +0200 Michał Górny mgo...@gentoo.org wrote: I believe we consider the user patches feature to be finalised, so if you want something else, it should be treated as a new feature rather than a change. But please don't rehash anything that's already been covered. I simply don't get why the spec obligates package managers to support user patches while it doesn't provide any explanation how the patches should be applied The spec does not obligate package managers to support user patches. It obligates ebuilds to support user packages. This was all covered in the original thread. nor any function to actually apply patches... Moving epatch into EAPI 5 is a separate feature, and one that's probably going to be controversial. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012, Ciaran McCreesh wrote: I believe we consider the user patches feature to be finalised, [...] I disagree with this. As it is currently worded, every ebuild would be required would be required to call a special function in src_prepare. This is the worst possible solution, IMHO. Ulrich
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012 17:44:36 +0200 Ulrich Mueller u...@gentoo.org wrote: On Wed, 20 Jun 2012, Ciaran McCreesh wrote: I believe we consider the user patches feature to be finalised, [...] I disagree with this. As it is currently worded, every ebuild would be required would be required to call a special function in src_prepare. This is the worst possible solution, IMHO. Every ebuild that defines its own src_prepare, yes. That's the point: the package mangler can't know where to apply patches itself otherwise, and user patches are rare enough that developers are very likely to forget to check if they aren't made to. We had this discussion in the original thread. If we're just looking for a feature that might work sometimes, there's no point sticking any of this in the EAPI at all. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 17:44:36 +0200 Ulrich Mueller u...@gentoo.org wrote: I disagree with this. As it is currently worded, every ebuild would be required to call a special function in src_prepare. This is the worst possible solution, IMHO. Every ebuild that defines its own src_prepare, yes. That's the point: the package mangler can't know where to apply patches itself otherwise, and user patches are rare enough that developers are very likely to forget to check if they aren't made to. Right, user patches are rare, and patches that change the build system such that eautoreconf is necessary are even rarer. I'd say that EAPI 5 should provide an apply_patches_here function that can be called by ebuilds, but if the ebuild hasn't called the function, then it should fall back to applying user patches just after src_prepare. We had this discussion in the original thread. If we're just looking for a feature that might work sometimes, there's no point sticking any of this in the EAPI at all. I don't see why the above wouldn't work. The user still has complete control, because he can always patch (e.g.) configure along with configure.in. Then there are ebuilds that don't call eautoreconf, in the first place. Should we require that all of them inherit autotools now, just for the unlikely case that user patches could be applied? Ulrich
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012 18:45:31 +0200 Ulrich Mueller u...@gentoo.org wrote: I'd say that EAPI 5 should provide an apply_patches_here function that can be called by ebuilds, but if the ebuild hasn't called the function, then it should fall back to applying user patches just after src_prepare. But applying user patches after src_prepare is wrong. We already had this discussion. We had this discussion in the original thread. If we're just looking for a feature that might work sometimes, there's no point sticking any of this in the EAPI at all. I don't see why the above wouldn't work. The user still has complete control, because he can always patch (e.g.) configure along with configure.in. Not really, since patches mess with timestamps. Then there are ebuilds that don't call eautoreconf, in the first place. Should we require that all of them inherit autotools now, just for the unlikely case that user patches could be applied? If the aim is to provide a working feature to users, yes. The alternative is to not provide user patches support. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Sun, 2012-06-17 at 13:35 +0200, Peter Stuge wrote: Hans de Graaff wrote: I think ABI fits well though? The situation is that A DEPENDs on B, and at some point B changes in a way that A must be rebuilt in order to run - right? At least for dev-ruby/nokogiri this is not the case. It checks the version of libxml2 it was built against versus the one it finds at runtime and starts to issue warnings if they don't match, but it will still run. Why does nokogiri issue warnings about something that isn't actually a problem? I haven't asked upstream, but my guess is that they are trying to be helpful by letting you run against new versions because this usually works out. rmagick is taking the alternative approach. dev-ruby/rmagick does something similar for imagemagick but actually refuses to run, even if the ABI would stay the same. ruby y u so weird? Well, it seems to me that you have to pick one of these two solutions as the sane one, or you must provide lock-step releases that refuse to build against untested new versions, which means locking in your users. Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About what would be included in EAPI5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/06/12 09:37 AM, Pacho Ramos wrote: El sáb, 16-06-2012 a las 13:43 +0100, Ciaran McCreesh escribió: On Sat, 16 Jun 2012 14:26:16 +0200 Pacho Ramos pa...@gentoo.org wrote: About suggesting new item (like forcing rebuilding of other packages as discussed some days ago and crosscompile support suggested by Tommy today), I guess we need to get them voted by the council? No. You need to get a draft diff for PMS written, along with an implementation in a package mangler of your choice and proof that it works in practice. Umm, this way to work makes any suggestion for future eapis to be accepted only if they come from people able to prepare that implementation in the package manager their prefer and, then, be stalled more and more time :| This makes sense to me - the original idea can come from anyone, but unless there is support by dev(s) that can maintain the package manager(s) and are willing to implement the proposed change, these ideas won't go anywhere anyways. Council can't make anything be implemented, after all. Also, if there is a working test implementation when the vote happens then it's a fairly quick process to full implementation once the EAPI is approved. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/fM1cACgkQ2ugaI38ACPDJkAD+I1Y/4BSTz8u6QAIepvFj7Pks HoKuSdhyEsZHhD9GGOUA/1qYM8uJ6SZBC3dfJnBQOpXo6ZLz3f7e4lbEIc1BXHbc =td0e -END PGP SIGNATURE-
Re: [gentoo-dev] About what would be included in EAPI5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/06/12 12:18 PM, Ciaran McCreesh wrote: On Sat, 16 Jun 2012 17:24:22 +0200 Peter Stuge pe...@stuge.se wrote: Ciaran McCreesh wrote: Could it work to make automatic signatures of imported ABI, and simply compare signatures when a provider package is updated? No. Can you say why? There's no way for a program to work out what the ABI of something is (whatever that means), and there's even less of a way for it to know up-front. I believe what Peter might've been referring to would be some form of hashing of each and every library that is installed by a package. Just as a basic idea, one could probably (for instance) grab the LTVERSION of a libtool-built library, store that along with the emerge info, and link this same version when consumer ebuilds are built against it; then if the signatures changes the consumer ebuilds that were built against the (now incompatible) old signatures could be triggered for a rebuild. I'm not saying that this is a viable approach, simply describing a theoretical way it could be implemented. One of the advantages of going this way, though, is that it would probably be EAPI-independent as everything would be done internally by the PMS. The primary disadvantages I see is that 1-getting library signatures would be difficult, 2-many orders of magnitude of additional preprocessing would be necessary to build the deptree, 3-there wouldn't be any viable way for developer-based intervention when necessary. Finally, the above is just an example; I don't want to discuss merits of an approach like this or entertain possible implementations. Also, can we stop using the term ABI in reference to this please? It's misleading. Let's call them sub-slots instead. I think ABI fits well though? The situation is that A DEPENDs on B, and at some point B changes in a way that A must be rebuilt in order to run - right? The only reason that A wouldn't run anymore is that B's ABI changed? ABI has a fairly specific, technical meaning, which can be misleading in the general case. Is Python bytecode an ABI? Isn't Python bytecode an ABI, given that it's built or tied to a particular version (major.minor) of python?? (i'm actually asking here, i avoid python so I don't really know if a .pyc from say python-2.5 will just work with python-2.7 or if the original script would need to be recompiled) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/fOPMACgkQ2ugaI38ACPCnpQD9Eu8uT2NABFQpb1ym5GeWUs0L SY+t0wWh6saGXyfVja8BAIYMB0Q21qukus/rH3gDdf98AZYgOiXA20tg+dQyHZ26 =grcA -END PGP SIGNATURE-
Re: [gentoo-dev] About what would be included in EAPI5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/06/12 12:24 PM, Ciaran McCreesh wrote: On Sat, 16 Jun 2012 17:16:34 +0200 Pacho Ramos pa...@gentoo.org wrote: I can try to check it if no maintainer shows more packages showing this stable API unstable ABIs issues Please do. This is a fairly important point: if the number of affected packages is small, there's no point in introducing sub-slots. I don't know about that -- I think we still very much need sub-slots. There is still a rather important distinction here -- SLOTS are currently used not to specify API, but to specify particular API groups that developers of said package are willing to support being installed (usually in parallel). For cases when developers decide it is not a good idea to support multiple APIs at a time (i go back to libpng here as an example of this current practice), 'SLOT=0' is still a valuable specification. Sub-slots will allow the actual API to be specified in this case (which as has been described will trigger rebuilds of consumers when necessary, if consumers *DEPEND on 'pkg:0=' or whatever the exact syntax will be) It's one thing for slot-operators in EAPI=5 to provide new tools to ensure better dependency handling; it's something else to assume the entire tree is going to be converted so that every package acting as a dependency will have a SLOT= reflecting the true API version rather than SLOT=0 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/fO/gACgkQ2ugaI38ACPBlNwD6Aw39lxsdGFSmHUqnzU+37A1P Z4x5TAtIrFsk7qK4y80A/RFpvD3J4YL8xonLKDWsey14BsKgq1Yz3VD5wlyDKJFd =FhFC -END PGP SIGNATURE-
Re: [gentoo-dev] About what would be included in EAPI5
On Sat, 2012-06-16 at 17:24 +0200, Peter Stuge wrote: Ciaran McCreesh wrote: Also, can we stop using the term ABI in reference to this please? It's misleading. Let's call them sub-slots instead. I think ABI fits well though? The situation is that A DEPENDs on B, and at some point B changes in a way that A must be rebuilt in order to run - right? At least for dev-ruby/nokogiri this is not the case. It checks the version of libxml2 it was built against versus the one it finds at runtime and starts to issue warnings if they don't match, but it will still run. So it would be a good idea to automatically update nokogiri after libxml2 to avoid cluttering logfiles and cron emails. But the ABI didn't change. dev-ruby/rmagick does something similar for imagemagick but actually refuses to run, even if the ABI would stay the same. Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About what would be included in EAPI5
Hans de Graaff wrote: I think ABI fits well though? The situation is that A DEPENDs on B, and at some point B changes in a way that A must be rebuilt in order to run - right? At least for dev-ruby/nokogiri this is not the case. It checks the version of libxml2 it was built against versus the one it finds at runtime and starts to issue warnings if they don't match, but it will still run. Why does nokogiri issue warnings about something that isn't actually a problem? So it would be a good idea to automatically update nokogiri after libxml2 to avoid cluttering logfiles and cron emails. But the ABI didn't change. Or fix this behavior upstream, if there is no actual reason to require the built-against version. dev-ruby/rmagick does something similar for imagemagick but actually refuses to run, even if the ABI would stay the same. ruby y u so weird? //Peter pgpGpQNzTkz7w.pgp Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Saturday 16 June 2012 08:12:13 Ulrich Mueller wrote: On Sat, 16 Jun 2012, Pacho Ramos wrote: I would like to know if there is some place where things going to be included (or proposed to be included) for eapi5 are listed (if such place exists). Currently, looks like there is no eapi5 tracker :-/ The PMS git repository has an eapi-5 development branch, and some parallel discussion took place in the gentoo-pms mailing list. So far we have: ╓ ║ EAPI 5 is EAPI 4 with the following changes: ║ ║ • econf adds --disable-silent-rules. ║ • Slot operator dependencies. ║ • src_test supports parallel tests. ║ • USE is calculated differently. ║ • IMAGE is gone. ║ • REQUIRED_USE now supports ?? groups. ║ • apply_user_patches function, with src_prepare changes. ║ • EBUILD_PHASE_FUNC. ║ • find is guaranteed to be GNU. ║ • new* can read from standard input. ╙ usex() should be there too considering its simplicity and the API already being ironed out and in active use -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] About what would be included in EAPI5
Hello I would like to know if there is some place where things going to be included (or proposed to be included) for eapi5 are listed (if such place exists). Currently, looks like there is no eapi5 tracker :-/ Thanks a lot for the info :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About what would be included in EAPI5
On Saturday 16 June 2012 12:55:22 Pacho Ramos wrote: Hello I would like to know if there is some place where things going to be included (or proposed to be included) for eapi5 are listed (if such place exists). Currently, looks like there is no eapi5 tracker :-/ Thanks a lot for the info :) maybe https://bugs.gentoo.org/show_bug.cgi?id=174380 ? -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About what would be included in EAPI5
El sáb, 16-06-2012 a las 13:13 +0200, Agostino Sarubbo escribió: On Saturday 16 June 2012 12:55:22 Pacho Ramos wrote: Hello I would like to know if there is some place where things going to be included (or proposed to be included) for eapi5 are listed (if such place exists). Currently, looks like there is no eapi5 tracker :-/ Thanks a lot for the info :) maybe https://bugs.gentoo.org/show_bug.cgi?id=174380 ? But it simply lists all reports filled suggesting new features to be included in future eapis... or maybe items to include in eapi5 are still pending to be decided by the council? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About what would be included in EAPI5
On Sat, 16 Jun 2012, Pacho Ramos wrote: I would like to know if there is some place where things going to be included (or proposed to be included) for eapi5 are listed (if such place exists). Currently, looks like there is no eapi5 tracker :-/ The PMS git repository has an eapi-5 development branch, and some parallel discussion took place in the gentoo-pms mailing list. So far we have: ╓ ║ EAPI 5 is EAPI 4 with the following changes: ║ ║ • econf adds --disable-silent-rules. ║ • Slot operator dependencies. ║ • src_test supports parallel tests. ║ • USE is calculated differently. ║ • IMAGE is gone. ║ • REQUIRED_USE now supports ?? groups. ║ • apply_user_patches function, with src_prepare changes. ║ • EBUILD_PHASE_FUNC. ║ • find is guaranteed to be GNU. ║ • new* can read from standard input. ╙ Ulrich
Re: [gentoo-dev] About what would be included in EAPI5
El sáb, 16-06-2012 a las 14:12 +0200, Ulrich Mueller escribió: On Sat, 16 Jun 2012, Pacho Ramos wrote: I would like to know if there is some place where things going to be included (or proposed to be included) for eapi5 are listed (if such place exists). Currently, looks like there is no eapi5 tracker :-/ The PMS git repository has an eapi-5 development branch, and some parallel discussion took place in the gentoo-pms mailing list. So far we have: ╓ ║ EAPI 5 is EAPI 4 with the following changes: ║ ║ • econf adds --disable-silent-rules. ║ • Slot operator dependencies. ║ • src_test supports parallel tests. ║ • USE is calculated differently. ║ • IMAGE is gone. ║ • REQUIRED_USE now supports ?? groups. ║ • apply_user_patches function, with src_prepare changes. ║ • EBUILD_PHASE_FUNC. ║ • find is guaranteed to be GNU. ║ • new* can read from standard input. ╙ Ulrich OK, would you let me to create a tracker bug for eapi5 accepted item? About suggesting new item (like forcing rebuilding of other packages as discussed some days ago and crosscompile support suggested by Tommy today), I guess we need to get them voted by the council? Thanks :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About what would be included in EAPI5
On Sat, 16 Jun 2012 14:26:16 +0200 Pacho Ramos pa...@gentoo.org wrote: OK, would you let me to create a tracker bug for eapi5 accepted item? No. We're working on the PMS list. We don't need yet another place to look. About suggesting new item (like forcing rebuilding of other packages as discussed some days ago and crosscompile support suggested by Tommy today), I guess we need to get them voted by the council? No. You need to get a draft diff for PMS written, along with an implementation in a package mangler of your choice and proof that it works in practice. The plan is we'll present the EAPI 5 branch to the Council and have them vote on each individual feature. Then we'll cherry-pick the ones they approve to master. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On 16.06.2012 14:26, Pacho Ramos wrote: El sáb, 16-06-2012 a las 14:12 +0200, Ulrich Mueller escribió: On Sat, 16 Jun 2012, Pacho Ramos wrote: I would like to know if there is some place where things going to be included (or proposed to be included) for eapi5 are listed (if such place exists). Currently, looks like there is no eapi5 tracker :-/ The PMS git repository has an eapi-5 development branch, and some parallel discussion took place in the gentoo-pms mailing list. So far we have: ╓ ║ EAPI 5 is EAPI 4 with the following changes: ║ ║ • econf adds --disable-silent-rules. ║ • Slot operator dependencies. ║ • src_test supports parallel tests. ║ • USE is calculated differently. ║ • IMAGE is gone. ║ • REQUIRED_USE now supports ?? groups. ║ • apply_user_patches function, with src_prepare changes. ║ • EBUILD_PHASE_FUNC. ║ • find is guaranteed to be GNU. ║ • new* can read from standard input. ╙ Ulrich OK, would you let me to create a tracker bug for eapi5 accepted item? About suggesting new item (like forcing rebuilding of other packages as discussed some days ago and crosscompile support suggested by Tommy today), I guess we need to get them voted by the council? Thanks :) At Fosdem Petteri talked about ideas for next EAPI, which brought up some discussions. Perhaps he or someone else who remembers could summarize the ideas. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About what would be included in EAPI5
El sáb, 16-06-2012 a las 13:43 +0100, Ciaran McCreesh escribió: On Sat, 16 Jun 2012 14:26:16 +0200 Pacho Ramos pa...@gentoo.org wrote: OK, would you let me to create a tracker bug for eapi5 accepted item? No. We're working on the PMS list. We don't need yet another place to look. About suggesting new item (like forcing rebuilding of other packages as discussed some days ago and crosscompile support suggested by Tommy today), I guess we need to get them voted by the council? No. You need to get a draft diff for PMS written, along with an implementation in a package mangler of your choice and proof that it works in practice. Umm, this way to work makes any suggestion for future eapis to be accepted only if they come from people able to prepare that implementation in the package manager their prefer and, then, be stalled more and more time :| The plan is we'll present the EAPI 5 branch to the Council and have them vote on each individual feature. Then we'll cherry-pick the ones they approve to master. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About what would be included in EAPI5
On Sat, 16 Jun 2012 15:37:44 +0200 Pacho Ramos pa...@gentoo.org wrote: About suggesting new item (like forcing rebuilding of other packages as discussed some days ago and crosscompile support suggested by Tommy today), I guess we need to get them voted by the council? No. You need to get a draft diff for PMS written, along with an implementation in a package mangler of your choice and proof that it works in practice. Umm, this way to work makes any suggestion for future eapis to be accepted only if they come from people able to prepare that implementation in the package manager their prefer and, then, be stalled more and more time :| It's more of a filter against people saying EAPI 5 should do blah! where no-one knows what blah actually is (and if you ask five people you get six answers) or how it should be implemented, or whether the implementation in any way works. The classic example is multilib: people keep saying EAPI n+1 should do multilib! where no-one has any idea what do multilib means. If you asked the Council to vote on that, they'd probably say yes, because multilib is good, but it's like politicians voting to say that by next year everyone should own a flying car. Your forcing rebuild is similar: the hard part is figuring out the problem. You may *think* you know what the issue is, but other people think it is something else, and in fact everyone is pretty much wrong on the whole thing. Until you've a) worked out what exactly you're tryin to solve (no-one has done this yet), b) worked out exactly what a solution is, and c) given the solution extensive testing on real packages to ensure that step a) didn't miss anything, talking to the Council is a waste of everyone's time. You are of course welcome to try to persuade someone else to do the work for you. That's what has happened for a good chunk of the current EAPI 5 list, and it's been the same for earlier EAPIs. But what you shouldn't do is expect a feature to be introduced just based upon a two sentence description, because the best outcome there is that we end up giving you something approximately related to what you wanted... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
El sáb, 16-06-2012 a las 14:48 +0100, Ciaran McCreesh escribió: On Sat, 16 Jun 2012 15:37:44 +0200 Pacho Ramos pa...@gentoo.org wrote: About suggesting new item (like forcing rebuilding of other packages as discussed some days ago and crosscompile support suggested by Tommy today), I guess we need to get them voted by the council? No. You need to get a draft diff for PMS written, along with an implementation in a package mangler of your choice and proof that it works in practice. Umm, this way to work makes any suggestion for future eapis to be accepted only if they come from people able to prepare that implementation in the package manager their prefer and, then, be stalled more and more time :| It's more of a filter against people saying EAPI 5 should do blah! where no-one knows what blah actually is (and if you ask five people you get six answers) or how it should be implemented, or whether the implementation in any way works. The classic example is multilib: people keep saying EAPI n+1 should do multilib! where no-one has any idea what do multilib means. If you asked the Council to vote on that, they'd probably say yes, because multilib is good, but it's like politicians voting to say that by next year everyone should own a flying car. Your forcing rebuild is similar: the hard part is figuring out the problem. You may *think* you know what the issue is, but other people think it is something else, and in fact everyone is pretty much wrong on the whole thing. Until you've a) worked out what exactly you're tryin to solve (no-one has done this yet), b) worked out exactly what a solution is, and c) given the solution extensive testing on real packages to ensure that step a) didn't miss anything, talking to the Council is a waste of everyone's time. You are of course welcome to try to persuade someone else to do the work for you. That's what has happened for a good chunk of the current EAPI 5 list, and it's been the same for earlier EAPIs. But what you shouldn't do is expect a feature to be introduced just based upon a two sentence description, because the best outcome there is that we end up giving you something approximately related to what you wanted... I thought last Zac suggestion of ABI_SLOT modified to use SLOT=ble/bla was clear enough and we reached a consensus. About what I am trying to solve, I have explained it multiple times in involved thread and won't repeat them once again. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About what would be included in EAPI5
On Sat, 16 Jun 2012 16:29:09 +0200 Pacho Ramos pa...@gentoo.org wrote: I thought last Zac suggestion of ABI_SLOT modified to use SLOT=ble/bla was clear enough and we reached a consensus. Possibly. I'm waiting to see an implementation, a bunch of examples and a comparison with just using SLOT and := or :*. About what I am trying to solve, I have explained it multiple times in involved thread and won't repeat them once again. Describing the problem clearly and correctly, and in the appropriate amount of generality, is the hardest and most important part of the process. Figuring out what we're trying to solve is far harder than writing a bit of code. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
El sáb, 16-06-2012 a las 15:31 +0100, Ciaran McCreesh escribió: On Sat, 16 Jun 2012 16:29:09 +0200 Pacho Ramos pa...@gentoo.org wrote: I thought last Zac suggestion of ABI_SLOT modified to use SLOT=ble/bla was clear enough and we reached a consensus. Possibly. I'm waiting to see an implementation, a bunch of examples and a comparison with just using SLOT and := or :*. I cannot provide you an implementation as I don't have enough skills to do it, no idea if maybe other dev/people could help on this :/ Regarding the comparison with using only SLOT, the most clear example of how that solution was a bit worse was that glib vs dbus-glib/gobject-introspection handling: - Using only SLOT with := would end up with we needing to update ebuilds for packages depending on glib on each SLOT bump, that is completely inviable. - I suggested then to be able to make that packages depend on :* (for example, dev-libs/glib:2.*:=, that way, that packages wouldn't need to get their ebuilds updated as they would still fit inside 2.* case, but would still get rebuild (as wanted) due := usage... but you also didn't like this approach. - Finally, we ended with SLOT=2/2.32 solution and packages depending on SLOT=2 (as currently) with the addition of := to get them rebuild when /2.32 changes. About what I am trying to solve, I have explained it multiple times in involved thread and won't repeat them once again. Describing the problem clearly and correctly, and in the appropriate amount of generality, is the hardest and most important part of the process. Figuring out what we're trying to solve is far harder than writing a bit of code. What I try to do is to replace the needing of manually rebuilding packages after updates due ABI changes, like currently occurs with xorg drivers, g-i and dbus-glib, ocaml-c based apps and cases like that. Regarding other problems like needing to use perl-cleaner, python-updater looks to be covered by another approach of dynamic slots I have just seen in gentoo-dev IRC channel by mgorny, then, that kind of issues would be uncovered with this (but maybe I am wrong as I know Zac had a more clear conception about how this ABI_SLOT way would work and what would it cover) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About what would be included in EAPI5
On Sat, 16 Jun 2012 16:48:20 +0200 Pacho Ramos pa...@gentoo.org wrote: Regarding the comparison with using only SLOT, the most clear example of how that solution was a bit worse was that glib vs dbus-glib/gobject-introspection handling: - Using only SLOT with := would end up with we needing to update ebuilds for packages depending on glib on each SLOT bump, that is completely inviable. What about if ranged dependencies existed? Also, we've yet to establish whether SLOT-with-/ really solves this problem, nor whether the problem is a general one. How many packages are there with stable APIs but unstable ABIs? - I suggested then to be able to make that packages depend on :* (for example, dev-libs/glib:2.*:=, that way, that packages wouldn't need to get their ebuilds updated as they would still fit inside 2.* case, but would still get rebuild (as wanted) due := usage... but you also didn't like this approach. You're misunderstanding the point of the * there. The * has nothing to do with wildcarding. About what I am trying to solve, I have explained it multiple times in involved thread and won't repeat them once again. Describing the problem clearly and correctly, and in the appropriate amount of generality, is the hardest and most important part of the process. Figuring out what we're trying to solve is far harder than writing a bit of code. What I try to do is to replace the needing of manually rebuilding packages after updates due ABI changes, like currently occurs with xorg drivers, g-i and dbus-glib, ocaml-c based apps and cases like that. See, that's not really a description of the problem. It's a good start, but I'd expect a full description to run to be several pages of detailed description of the general case, along with worked out examples. This isn't an easy issue, and we don't want to come up with a solution that works for one particular package whilst ignoring the needs of everything else. Regarding other problems like needing to use perl-cleaner, python-updater looks to be covered by another approach of dynamic slots I have just seen in gentoo-dev IRC channel by mgorny, then, that kind of issues would be uncovered with this (but maybe I am wrong as I know Zac had a more clear conception about how this ABI_SLOT way would work and what would it cover) Somehow I don't think this cunning plan has been thought all the way through... Coming up with a solution rather than a description of the problem is the wrong thing to do. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Sat, 16 Jun 2012 16:48:20 +0200 Pacho Ramos pa...@gentoo.org wrote: El sáb, 16-06-2012 a las 15:31 +0100, Ciaran McCreesh escribió: On Sat, 16 Jun 2012 16:29:09 +0200 Pacho Ramos pa...@gentoo.org wrote: I thought last Zac suggestion of ABI_SLOT modified to use SLOT=ble/bla was clear enough and we reached a consensus. Possibly. I'm waiting to see an implementation, a bunch of examples and a comparison with just using SLOT and := or :*. I cannot provide you an implementation as I don't have enough skills to do it, no idea if maybe other dev/people could help on this :/ Zac is already working on this. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
Pacho Ramos wrote: What I try to do is to replace the needing of manually rebuilding packages after updates due ABI changes Does this really require explicit ABI information in ebuilds? Could it work to make automatic signatures of imported ABI, and simply compare signatures when a provider package is updated? //Peter pgphg407Hi62N.pgp Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Sat, 16 Jun 2012 17:06:07 +0200 Peter Stuge pe...@stuge.se wrote: Could it work to make automatic signatures of imported ABI, and simply compare signatures when a provider package is updated? No. Also, can we stop using the term ABI in reference to this please? It's misleading. Let's call them sub-slots instead. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
El sáb, 16-06-2012 a las 15:52 +0100, Ciaran McCreesh escribió: On Sat, 16 Jun 2012 16:48:20 +0200 Pacho Ramos pa...@gentoo.org wrote: Regarding the comparison with using only SLOT, the most clear example of how that solution was a bit worse was that glib vs dbus-glib/gobject-introspection handling: - Using only SLOT with := would end up with we needing to update ebuilds for packages depending on glib on each SLOT bump, that is completely inviable. What about if ranged dependencies existed? I think this was already discussed in the same thread, but maybe we are thinking in different things, could you please explain me a bit more what do you mean by ranged dependencies? (if it would include an example, even better :)) Also, we've yet to establish whether SLOT-with-/ really solves this problem, nor whether the problem is a general one. How many packages are there with stable APIs but unstable ABIs? Good point, if other maintainers don't talk about their packages (as they will for sure know why they need rebuilding exactly), would need to grep in the tree looking for rebuild instructions for figure out :/, I can try to check it if no maintainer shows more packages showing this stable API unstable ABIs issues - I suggested then to be able to make that packages depend on :* (for example, dev-libs/glib:2.*:=, that way, that packages wouldn't need to get their ebuilds updated as they would still fit inside 2.* case, but would still get rebuild (as wanted) due := usage... but you also didn't like this approach. You're misunderstanding the point of the * there. The * has nothing to do with wildcarding. Probably, what is * sense in this context? I was thinking more on a bash context when I would use * to fit any 2.x case About what I am trying to solve, I have explained it multiple times in involved thread and won't repeat them once again. Describing the problem clearly and correctly, and in the appropriate amount of generality, is the hardest and most important part of the process. Figuring out what we're trying to solve is far harder than writing a bit of code. What I try to do is to replace the needing of manually rebuilding packages after updates due ABI changes, like currently occurs with xorg drivers, g-i and dbus-glib, ocaml-c based apps and cases like that. See, that's not really a description of the problem. It's a good start, but I'd expect a full description to run to be several pages of detailed description of the general case, along with worked out examples. This isn't an easy issue, and we don't want to come up with a solution that works for one particular package whilst ignoring the needs of everything else. Regarding other problems like needing to use perl-cleaner, python-updater looks to be covered by another approach of dynamic slots I have just seen in gentoo-dev IRC channel by mgorny, then, that kind of issues would be uncovered with this (but maybe I am wrong as I know Zac had a more clear conception about how this ABI_SLOT way would work and what would it cover) Somehow I don't think this cunning plan has been thought all the way through... Coming up with a solution rather than a description of the problem is the wrong thing to do. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About what would be included in EAPI5
El sáb, 16-06-2012 a las 17:16 +0200, Pacho Ramos escribió: El sáb, 16-06-2012 a las 15:52 +0100, Ciaran McCreesh escribió: On Sat, 16 Jun 2012 16:48:20 +0200 Pacho Ramos pa...@gentoo.org wrote: Regarding the comparison with using only SLOT, the most clear example of how that solution was a bit worse was that glib vs dbus-glib/gobject-introspection handling: - Using only SLOT with := would end up with we needing to update ebuilds for packages depending on glib on each SLOT bump, that is completely inviable. What about if ranged dependencies existed? I think this was already discussed in the same thread, but maybe we are thinking in different things, could you please explain me a bit more what do you mean by ranged dependencies? (if it would include an example, even better :)) Also, we've yet to establish whether SLOT-with-/ really solves this problem, nor whether the problem is a general one. How many packages are there with stable APIs but unstable ABIs? Good point, if other maintainers don't talk about their packages (as they will for sure know why they need rebuilding exactly), would need to grep in the tree looking for rebuild instructions for figure out :/, I can try to check it if no maintainer shows more packages showing this stable API unstable ABIs issues Also, maybe you could talk with other exherbo maintainers as I am sure they have also experienced this kind of problem (packages needing to be rebuilt after update of other one), maybe they could join forces with us to try to reach an exact description of the problem and a solution :/ - I suggested then to be able to make that packages depend on :* (for example, dev-libs/glib:2.*:=, that way, that packages wouldn't need to get their ebuilds updated as they would still fit inside 2.* case, but would still get rebuild (as wanted) due := usage... but you also didn't like this approach. You're misunderstanding the point of the * there. The * has nothing to do with wildcarding. Probably, what is * sense in this context? I was thinking more on a bash context when I would use * to fit any 2.x case About what I am trying to solve, I have explained it multiple times in involved thread and won't repeat them once again. Describing the problem clearly and correctly, and in the appropriate amount of generality, is the hardest and most important part of the process. Figuring out what we're trying to solve is far harder than writing a bit of code. What I try to do is to replace the needing of manually rebuilding packages after updates due ABI changes, like currently occurs with xorg drivers, g-i and dbus-glib, ocaml-c based apps and cases like that. See, that's not really a description of the problem. It's a good start, but I'd expect a full description to run to be several pages of detailed description of the general case, along with worked out examples. This isn't an easy issue, and we don't want to come up with a solution that works for one particular package whilst ignoring the needs of everything else. Regarding other problems like needing to use perl-cleaner, python-updater looks to be covered by another approach of dynamic slots I have just seen in gentoo-dev IRC channel by mgorny, then, that kind of issues would be uncovered with this (but maybe I am wrong as I know Zac had a more clear conception about how this ABI_SLOT way would work and what would it cover) Somehow I don't think this cunning plan has been thought all the way through... Coming up with a solution rather than a description of the problem is the wrong thing to do. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About what would be included in EAPI5
Ciaran McCreesh wrote: Could it work to make automatic signatures of imported ABI, and simply compare signatures when a provider package is updated? No. Can you say why? Also, can we stop using the term ABI in reference to this please? It's misleading. Let's call them sub-slots instead. I think ABI fits well though? The situation is that A DEPENDs on B, and at some point B changes in a way that A must be rebuilt in order to run - right? The only reason that A wouldn't run anymore is that B's ABI changed? Slots and sub-slots seem to be PMS terms to model this situation? They could certainly be used to implement a solution, but perhaps it's wise not to insist on using them when merely exploring the problem? //Peter pgpbnR0TXd0wq.pgp Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Sat, 16 Jun 2012 17:24:22 +0200 Peter Stuge pe...@stuge.se wrote: Ciaran McCreesh wrote: Could it work to make automatic signatures of imported ABI, and simply compare signatures when a provider package is updated? No. Can you say why? There's no way for a program to work out what the ABI of something is (whatever that means), and there's even less of a way for it to know up-front. Also, can we stop using the term ABI in reference to this please? It's misleading. Let's call them sub-slots instead. I think ABI fits well though? The situation is that A DEPENDs on B, and at some point B changes in a way that A must be rebuilt in order to run - right? The only reason that A wouldn't run anymore is that B's ABI changed? ABI has a fairly specific, technical meaning, which can be misleading in the general case. Is Python bytecode an ABI? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Sat, 16 Jun 2012 17:16:34 +0200 Pacho Ramos pa...@gentoo.org wrote: El sáb, 16-06-2012 a las 15:52 +0100, Ciaran McCreesh escribió: On Sat, 16 Jun 2012 16:48:20 +0200 Pacho Ramos pa...@gentoo.org wrote: Regarding the comparison with using only SLOT, the most clear example of how that solution was a bit worse was that glib vs dbus-glib/gobject-introspection handling: - Using only SLOT with := would end up with we needing to update ebuilds for packages depending on glib on each SLOT bump, that is completely inviable. What about if ranged dependencies existed? I think this was already discussed in the same thread, but maybe we are thinking in different things, could you please explain me a bit more what do you mean by ranged dependencies? (if it would include an example, even better :)) Being able to say something like =23. I can try to check it if no maintainer shows more packages showing this stable API unstable ABIs issues Please do. This is a fairly important point: if the number of affected packages is small, there's no point in introducing sub-slots. You're misunderstanding the point of the * there. The * has nothing to do with wildcarding. Probably, what is * sense in this context? I was thinking more on a bash context when I would use * to fit any 2.x case It means and the slot can be switched at runtime, without causing breakage. Thus it's only meaningful on dependencies that are both build- and run-. The :*/:= feature was designed to solve one specific problem: if a user has foo installed, and foo deps upon bar, and bar:1 is installed, and the user wants to install bar:2 and then uninstall bar:1, will foo break? :* means no, := means yes. Also, maybe you could talk with other exherbo maintainers as I am sure they have also experienced this kind of problem (packages needing to be rebuilt after update of other one), maybe they could join forces with us to try to reach an exact description of the problem and a solution :/ I'm pretty sure the route Exherbo is going to take with this is very different, and will involve souped-up USE flags that allow parts of a package (such as its libraries) to be kept around, possibly together with a special form of blocker that acts only upon installed packages, with a strict post ordering. It's not going to involve sub-slots, in any case. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
El sáb, 16-06-2012 a las 17:24 +0100, Ciaran McCreesh escribió: On Sat, 16 Jun 2012 17:16:34 +0200 Pacho Ramos pa...@gentoo.org wrote: El sáb, 16-06-2012 a las 15:52 +0100, Ciaran McCreesh escribió: On Sat, 16 Jun 2012 16:48:20 +0200 Pacho Ramos pa...@gentoo.org wrote: Regarding the comparison with using only SLOT, the most clear example of how that solution was a bit worse was that glib vs dbus-glib/gobject-introspection handling: - Using only SLOT with := would end up with we needing to update ebuilds for packages depending on glib on each SLOT bump, that is completely inviable. What about if ranged dependencies existed? I think this was already discussed in the same thread, but maybe we are thinking in different things, could you please explain me a bit more what do you mean by ranged dependencies? (if it would include an example, even better :)) Being able to say something like =23. I can try to check it if no maintainer shows more packages showing this stable API unstable ABIs issues Please do. This is a fairly important point: if the number of affected packages is small, there's no point in introducing sub-slots. Simply grepping for qfile usages, I see similar problems for gtk +/gdk-pixbuf and any package providing /usr/lib/gtk-2.0/2.* files. Also similar problem with PyQt4 packages, and sip ones. And this is not counting packages that tell people to manually run emerge 'some package' directly You're misunderstanding the point of the * there. The * has nothing to do with wildcarding. Probably, what is * sense in this context? I was thinking more on a bash context when I would use * to fit any 2.x case It means and the slot can be switched at runtime, without causing breakage. Thus it's only meaningful on dependencies that are both build- and run-. The :*/:= feature was designed to solve one specific problem: if a user has foo installed, and foo deps upon bar, and bar:1 is installed, and the user wants to install bar:2 and then uninstall bar:1, will foo break? :* means no, := means yes. And, wouldn't it be covered simply making that package not depend on any slot specifically? Also, maybe you could talk with other exherbo maintainers as I am sure they have also experienced this kind of problem (packages needing to be rebuilt after update of other one), maybe they could join forces with us to try to reach an exact description of the problem and a solution :/ I'm pretty sure the route Exherbo is going to take with this is very different, and will involve souped-up USE flags that allow parts of a package (such as its libraries) to be kept around, possibly together with a special form of blocker that acts only upon installed packages, with a strict post ordering. It's not going to involve sub-slots, in any case. Well, probably the problem is to predict when will that be really solved there :( signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About what would be included in EAPI5
On Sat, 16 Jun 2012 18:41:51 +0200 Pacho Ramos pa...@gentoo.org wrote: The :*/:= feature was designed to solve one specific problem: if a user has foo installed, and foo deps upon bar, and bar:1 is installed, and the user wants to install bar:2 and then uninstall bar:1, will foo break? :* means no, := means yes. And, wouldn't it be covered simply making that package not depend on any slot specifically? Some people use no slot to mean and it's fixed at build time, and some use it to mean and I don't care. We *could* just omit :*, and use := for locking, but an explicit :* means someone has checked their work (and can be verified by repoman) whereas no slot probably means laziness. I'm pretty sure the route Exherbo is going to take with this is very different, and will involve souped-up USE flags that allow parts of a package (such as its libraries) to be kept around, possibly together with a special form of blocker that acts only upon installed packages, with a strict post ordering. It's not going to involve sub-slots, in any case. Well, probably the problem is to predict when will that be really solved there :( Naah. This is one of those things that requires developers to put quite a lot of exta effort in to their packages in order to improve the quality of experience for users, which means it's not going to be suitable for Gentoo's development model. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
El sáb, 16-06-2012 a las 17:46 +0100, Ciaran McCreesh escribió: On Sat, 16 Jun 2012 18:41:51 +0200 Pacho Ramos pa...@gentoo.org wrote: The :*/:= feature was designed to solve one specific problem: if a user has foo installed, and foo deps upon bar, and bar:1 is installed, and the user wants to install bar:2 and then uninstall bar:1, will foo break? :* means no, := means yes. And, wouldn't it be covered simply making that package not depend on any slot specifically? Some people use no slot to mean and it's fixed at build time, and some use it to mean and I don't care. We *could* just omit :*, and use := for locking, but an explicit :* means someone has checked their work (and can be verified by repoman) whereas no slot probably means laziness. I'm pretty sure the route Exherbo is going to take with this is very different, and will involve souped-up USE flags that allow parts of a package (such as its libraries) to be kept around, possibly together with a special form of blocker that acts only upon installed packages, with a strict post ordering. It's not going to involve sub-slots, in any case. Well, probably the problem is to predict when will that be really solved there :( Naah. This is one of those things that requires developers to put quite a lot of exta effort in to their packages in order to improve the quality of experience for users, which means it's not going to be suitable for Gentoo's development model. Well, not all people have infinite time to put that huge effort you sometimes would demand us to make things work perfectly :| (and looks like Exherbo developer also have the same problem as this model is still not implemented there, no? And that is normal, they also have time constraints for sure) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About what would be included in EAPI5
On Sat, 16 Jun 2012 20:59:18 +0200 Pacho Ramos pa...@gentoo.org wrote: Naah. This is one of those things that requires developers to put quite a lot of exta effort in to their packages in order to improve the quality of experience for users, which means it's not going to be suitable for Gentoo's development model. Well, not all people have infinite time to put that huge effort you sometimes would demand us to make things work perfectly :| There are two problems with that answer. Firstly, if getting something right takes a developer an extra ten minutes but saves each user one second of effort, it should be considered highly worthwhile. The fact that it isn't reflects very poorly upon Gentoo's attitude towards its users. Secondly, most of Gentoo's effort these days seems to be being spent cleaning up self-inflicted problems. Technical debt really is an issue here. By not doing things properly now, you're just adding to the problems facing future developers. (and looks like Exherbo developer also have the same problem as this model is still not implemented there, no? And that is normal, they also have time constraints for sure) Exherbo's generally pretty good at rewrite all the packages! type things. Partly that's because there are fewer packages (but then there are much better mechanisms for handling unpackaged packages), but it's also because QA and having a clean architecture are taken seriously there. Exherbo does have := and :*, and makes heavier use of slotting than Gentoo (partly due to having a much better 'alternatives' implementation). It doesn't have parts, because I've not had time to work out exactly how to get the resolver to do them cleanly. Once the package mangler side is done, experience has shown that there will be a very short delay before every relevant package is using it. -- Ciaran McCreesh signature.asc Description: PGP signature
