Re: [gentoo-dev] RFC: Deprecating EAPI0
Ciaran McCreesh wrote: Uhm. Do you think these ideas of yours through at all before posting them? Being rude doesn't make you cool. (Nor make your points more effective) Either you think the entire tree should be switched to a new EAPI in one go, in which case how on earth is that going to get done, or you don't, in which case there's no point to branches, and any migration can be done using a simple tag. I'd like you to rethink your statement and then come again. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Wed, 25 Mar 2009 10:19:12 +0100 Luca Barbato lu_z...@gentoo.org wrote: Ciaran McCreesh wrote: Uhm. Do you think these ideas of yours through at all before posting them? Being rude doesn't make you cool. (Nor make your points more effective) That's not being rude. It's an attempt to bring your attention to the fact that other people read what you right, so you're doing them a discourtesy by wasting their time by repeatedly posting ideas you haven't thought through and that aren't even remotely workable. Either you think the entire tree should be switched to a new EAPI in one go, in which case how on earth is that going to get done, or you don't, in which case there's no point to branches, and any migration can be done using a simple tag. I'd like you to rethink your statement and then come again. We've been over this before. The whole point of EAPI is that it avoids the need for mass tree changes. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Wednesday 25 of March 2009 15:19:36 Ciaran McCreesh wrote: Being rude doesn't make you cool. (Nor make your points more effective) That's not being rude. [...] (no comment) so you're doing them a discourtesy by wasting their time by repeatedly posting ideas you haven't thought through [...] Considering average post count and Gentoo membership on that list, I'm pretty convinced you're not entitled to decide who is wasting developers' time. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Wed, 25 Mar 2009 20:06:47 +0100 Maciej Mrozowski reave...@poczta.fm wrote: Considering average post count and Gentoo membership on that list, I'm pretty convinced you're not entitled to decide who is wasting developers' time. When you've gained enough experience and knowledge to be able to evaluate the merits of proposals, I invite you to rethink those comments and deliver your apology. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Wed, Mar 25, 2009 at 12:13 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 25 Mar 2009 20:06:47 +0100 Maciej Mrozowski reave...@poczta.fm wrote: Considering average post count and Gentoo membership on that list, I'm pretty convinced you're not entitled to decide who is wasting developers' time. When you've gained enough experience and knowledge to be able to evaluate the merits of proposals, I invite you to rethink those comments and deliver your apology. Please feel free to continue this conversation off list (both sides). If you want to call people rude farts, do it on your own time, not on my list. -A -- Ciaran McCreesh
Re: [gentoo-dev] RFC: Deprecating EAPI0
Patrick Lauer wrote: [deprecating stuff] I'd rather switch to git first, have eapi in separate branches then, make sure we can provide eapi-N compatibility/migration tree snapshots and then warn people so there will be a easy way to provide fallbacks. Before that I'm afraid it would take too much. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Tue, 24 Mar 2009 12:40:05 +0100 Luca Barbato lu_z...@gentoo.org wrote: I'd rather switch to git first, have eapi in separate branches then, make sure we can provide eapi-N compatibility/migration tree snapshots and then warn people so there will be a easy way to provide fallbacks. Uhm. Do you think these ideas of yours through at all before posting them? Either you think the entire tree should be switched to a new EAPI in one go, in which case how on earth is that going to get done, or you don't, in which case there's no point to branches, and any migration can be done using a simple tag. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Saturday 21 March 2009 19:03:45 AllenJB wrote: Patrick Lauer wrote: Hi all, with the discussion about EAPI3 we have now 4 (or 7, depending on how you count them ;) ) EAPIs available or almost available. This is getting quite confusing. To make our lives easier I would suggest deprecating EAPI0 and migrating existing ebuilds over some time to EAPI1 or higher until EAPI0 can be obsoleted at some point in the future. I would set the start of deprecation warnings about 3 months from now and the obsoletion quite a time later, maybe 12 months from now, when a sufficient amount of ebuilds has been migrated. Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to think about, but since it has some changes like adding src_prepare migration would not be as trivial. So I'd prefer keeping it around a bit longer. Comments? Patrick While there definitely arguments for deprecating EAPIs, I would suggest caution. A low number of active EAPIs can make life easier for developers, but it can also make life harder for some users. There are still users coming to the forums upgrading systems which only understand EAPI 0. I accept that Gentoo is certainly a relatively fast moving distro, but I think that developers also do need to consider users who have systems that are currently just working and may not upgrade often (once a year or even less) As such, I would suggest that forcing a move to the most recent stable EAPI is possibly unwise. snip AllenJB Note, this just my opinion. It may not be entirely practical or cover all the issues regarding backwards compatibility. I intend it to provoke questions and thought as to what a reasonable policy for backwards compatibility might cover. Waiting a year or longer to upgrade a gentoo system carries a good risk of having something explode into a near unrecoverable mess. I definitely do think that some major focus needs to be placed on how far behind a gentoo system could be and should still be expected to catch up. An oversimplified example. Assume that I can find all required patches and source code to do the initial builds, and that all normal configuration file checks/updates are done after the current tree is installed. I create three different virtual machines from cvs snapshots of the portage tree. The first is dated 6 months ago. The second is dated 12 months ago. The third is dated 18 months ago. Which of these should be reasonably updateable to the current portage tree? My suggestion is that policy should allow machine 1 to be updated through regular update procedures to the current tree, unless major changes dictate otherwise. Major changes being incompatible ebuild formats, toolchains, and other here is the line sorry kind of changes. A careful operator should probably be able get machine 2 updated to the current tree, again unless major changes dictate otherwise. We should not make go out of our way to make upgrading from this point out hard for the operator, but, new growth should be favored over the ease of upgrading. Machine 3 is just out of luck. Here is the new install cd and handbook, have fun. Regular update procedures would be: emerge --sync; emerge -uND world -f; emerge -uND world; revdep-rebuild; emerge --depclean; The careful operator might update the toolchain first and emerge -e world or something similar.
Re: [gentoo-dev] RFC: Deprecating EAPI0
Peter Alfredsen loki_...@gentoo.org wrote: I think we should start deprecating EAPI=0 usage *now* with a repoman warning whenever a new ebuild is committed that does not use EAPI=1 or EAPI=2. This warning should encourage use of the newest EAPI, EAPI=2. A general question, that just popped into my head when i was reading this: if i touch a ebuild which has EAPI=0, should i bump it to EAPI=2? Since the introduction of EAPI i have been bumping EAPI of my ebuilds based on need. So if i needed slot-deps, i've made the ebuild EAPI=1, not EAPI=2 by choice. If i needed use-deps, then well, i went for EAPI=2. How are other ebuild developers doing this? What's the package manager ppls take on this? -- Regards, Matti Bickel Signed/Encrypted email preferred (key 4849EC6C) pgpr5TMoF3mbY.pgp Description: PGP signature
EAPI roadmap (was: Re: [gentoo-dev] RFC: Deprecating EAPI0)
Peter Alfredsen loki_...@gentoo.org said: On Sun, 22 Mar 2009 09:41:58 +0100 Matti Bickel m...@gentoo.org wrote: A general question, that just popped into my head when i was reading this: if i touch a ebuild which has EAPI=0, should i bump it to EAPI=2? Only if you take the time to read through it and test that your revised ebuild will have the same functionality as the old one. That's why I wrote when a new ebuild This should not be an automated thing, but rather a part of the basic bump-adjust-test maintenance cycle. while i agree with what you say here, it is also important to take the general EAPI roadmap into account. as we currently dont have one AFAIK, we should make efforts to agree on one soon. i doesnt make sense to introduce EAPI=2 into ebuilds, if we dont expect to have en EAPI=2 capable package manager stable within a reasonable timeframe. as it really doesnt matter what i think, when portage-2.2 should go stable i will not bore you with that, however, given that only portage 2.2 supports EAPI=2 it is relevant for the discussion of an EAPI roadmap. in light of the current EAPI usage statistics, i would propose to deprecate EAPI 1 (and 2) much earlier than EAPI 0. regards Thilo /loki_val
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Saturday 21 of March 2009 21:53:16 Patrick Lauer wrote: On Saturday 21 March 2009 21:21:47 Ciaran McCreesh wrote: On Sat, 21 Mar 2009 18:37:12 +0100 Patrick Lauer patr...@gentoo.org wrote: To make our lives easier I would suggest deprecating EAPI0 and migrating existing ebuilds over some time to EAPI1 or higher until EAPI0 can be obsoleted at some point in the future. Uh. Why? Because, as you have noticed before, developers get confused which eapi has which features available. And eapi1 is a superset of eapi0, so we don't have to rewrite tons of things. Spend more time to teach them. It's easier to developers make sure they do things ok than users spending their time to figure out what's wrong. Personally i don't like the idea of deprecating EAPI0 since it may break many servers. Eg. our border router at work isn't upgraded regulary. I spent much time lately to upgrade it with problems like portage vs. bash and so. So the last thing i'd like to see now in portage is implementing your proposal. Introducing a policy encouraging moving things that definitely aren't in the least bit likely to be a system dep on a bump, sure. Making 1 or 2 the default for new packages, sure. But rewriting existing things? That's just an accident waiting to happen. What kind of accident do you expect to happen? Patrick
[gentoo-dev] RFC: Deprecating EAPI0
Hi all, with the discussion about EAPI3 we have now 4 (or 7, depending on how you count them ;) ) EAPIs available or almost available. This is getting quite confusing. To make our lives easier I would suggest deprecating EAPI0 and migrating existing ebuilds over some time to EAPI1 or higher until EAPI0 can be obsoleted at some point in the future. I would set the start of deprecation warnings about 3 months from now and the obsoletion quite a time later, maybe 12 months from now, when a sufficient amount of ebuilds has been migrated. Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to think about, but since it has some changes like adding src_prepare migration would not be as trivial. So I'd prefer keeping it around a bit longer. Comments? Patrick
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Sat, Mar 21, 2009 at 10:37 AM, Patrick Lauer patr...@gentoo.org wrote: Hi all, with the discussion about EAPI3 we have now 4 (or 7, depending on how you count them ;) ) EAPIs available or almost available. This is getting quite confusing. Be more specific, what actual problems have you encountered? What are some other ways we could mitigate these issues (it seems like tool improvements could be a big one here)? To make our lives easier I would suggest deprecating EAPI0 and migrating existing ebuilds over some time to EAPI1 or higher until EAPI0 can be obsoleted at some point in the future. I would set the start of deprecation warnings about 3 months from now and the obsoletion quite a time later, maybe 12 months from now, when a sufficient amount of ebuilds has been migrated. I am interested in the number of ebuilds at specific APIs in the tree, do you have those numbers? Basically, how much work is this (raw ebuild count)? Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to think about, but since it has some changes like adding src_prepare migration would not be as trivial. So I'd prefer keeping it around a bit longer. Comments? Patrick
Re: [gentoo-dev] RFC: Deprecating EAPI0
Alec Warner schrieb am 21.03.2009 20:45: Be more specific, what actual problems have you encountered? What are some other ways we could mitigate these issues (it seems like tool improvements could be a big one here)? Regarding the depreciation of EAPI's I think eclasses will probably benefit from a low number of possible EAPI's. I am thinking about the introduction of more and more EAPI's which all need to be considered in the eclasses which will get tedious. Regards, Daniel
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Sat, 21 Mar 2009 18:37:12 +0100 Patrick Lauer patr...@gentoo.org wrote: To make our lives easier I would suggest deprecating EAPI0 and migrating existing ebuilds over some time to EAPI1 or higher until EAPI0 can be obsoleted at some point in the future. Uh. Why? Introducing a policy encouraging moving things that definitely aren't in the least bit likely to be a system dep on a bump, sure. Making 1 or 2 the default for new packages, sure. But rewriting existing things? That's just an accident waiting to happen. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Saturday 21 March 2009 19:37:12 Patrick Lauer wrote: Hi all, with the discussion about EAPI3 we have now 4 (or 7, depending on how you count them ;) ) EAPIs available or almost available. This is getting quite confusing. To make our lives easier I would suggest deprecating EAPI0 and migrating existing ebuilds over some time to EAPI1 or higher until EAPI0 can be obsoleted at some point in the future. I would set the start of deprecation warnings about 3 months from now and the obsoletion quite a time later, maybe 12 months from now, when a sufficient amount of ebuilds has been migrated. Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to think about, but since it has some changes like adding src_prepare migration would not be as trivial. So I'd prefer keeping it around a bit longer. Comments? Patrick The gain obtained by this migration doesnt compensate for the efford/work one (we) must put into this. But if we decide to mark EAPI0 as deprecated, first it would be nice to have a tree cleanup cause it doesn't make much sense to migrate broken/unmaintained/old/etc ebuilds onto newer EAPIs. -- Markos Chandras (hwoarang) Gentoo Linux Developer KDE/Qt/Sunrise/Sound Web: http://hwoarang.silverarrow.gr signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Deprecating EAPI0
Alec Warner wrote: I am interested in the number of ebuilds at specific APIs in the tree, do you have those numbers? Basically, how much work is this (raw ebuild count)? Total ebuilds 26209 EAPI0 ebuilds 22880 EAPI1 ebuilds 1855 EAPI2 ebuilds 1474 this numbers based on regexps =) -- Alexey 'Alexxy' Shvetsov Gentoo/KDE Gentoo/MIPS Gentoo/SCI Gentoo Team Ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Saturday 21 March 2009 21:21:47 Ciaran McCreesh wrote: On Sat, 21 Mar 2009 18:37:12 +0100 Patrick Lauer patr...@gentoo.org wrote: To make our lives easier I would suggest deprecating EAPI0 and migrating existing ebuilds over some time to EAPI1 or higher until EAPI0 can be obsoleted at some point in the future. Uh. Why? Because, as you have noticed before, developers get confused which eapi has which features available. And eapi1 is a superset of eapi0, so we don't have to rewrite tons of things. Introducing a policy encouraging moving things that definitely aren't in the least bit likely to be a system dep on a bump, sure. Making 1 or 2 the default for new packages, sure. But rewriting existing things? That's just an accident waiting to happen. What kind of accident do you expect to happen? Patrick
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Sat, 21 Mar 2009 21:53:16 +0100 Patrick Lauer patr...@gentoo.org wrote: Because, as you have noticed before, developers get confused which eapi has which features available. And eapi1 is a superset of eapi0, so we don't have to rewrite tons of things. So? When people do new things, they can move the EAPI forward. That's not a reason to modify existing things. Introducing a policy encouraging moving things that definitely aren't in the least bit likely to be a system dep on a bump, sure. Making 1 or 2 the default for new packages, sure. But rewriting existing things? That's just an accident waiting to happen. What kind of accident do you expect to happen? The same kind that always happens when lots of ebuilds get changed. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Deprecating EAPI0
Alexey Shvetsov wrote: Alec Warner wrote: I am interested in the number of ebuilds at specific APIs in the tree, do you have those numbers? Basically, how much work is this (raw ebuild count)? Total ebuilds 26209 EAPI0 ebuilds 22880 EAPI1 ebuilds 1855 EAPI2 ebuilds 1474 this numbers based on regexps =) With these numbers, I don't exactly see the point of deprecating EAPI0. Too much work that we could be spending elsewhere.. Although, I suppose someone will propose to make the default EAPI be 1 instead of 0. I don't see a point for that either. -Jeremy
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Saturday 21 March 2009 21:55:20 Ciaran McCreesh wrote: On Sat, 21 Mar 2009 21:53:16 +0100 Patrick Lauer patr...@gentoo.org wrote: Because, as you have noticed before, developers get confused which eapi has which features available. And eapi1 is a superset of eapi0, so we don't have to rewrite tons of things. So? When people do new things, they can move the EAPI forward. That's not a reason to modify existing things. The added complexity of having a dozen eapis does not offer any benefits to the average developer. Limiting the amount of complexity tends to reduce the amount of errors, be it simple developer mistakes or unexpected interaction errors between different EAPIs in the package manager. Introducing a policy encouraging moving things that definitely aren't in the least bit likely to be a system dep on a bump, sure. Making 1 or 2 the default for new packages, sure. But rewriting existing things? That's just an accident waiting to happen. What kind of accident do you expect to happen? The same kind that always happens when lots of ebuilds get changed. ... lots of new features and a few bugs that get fixed the next day? Hey, that sounds quite bad. And maybe some new herd testers? How rude! So what technical reason(s) do we have to keep archaic EAPIs around forever? Patrick
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Sat, 21 Mar 2009 22:02:54 +0100 Patrick Lauer patr...@gentoo.org wrote: So? When people do new things, they can move the EAPI forward. That's not a reason to modify existing things. The added complexity of having a dozen eapis does not offer any benefits to the average developer. There is no added complexity. Those things are already there. The same kind that always happens when lots of ebuilds get changed. ... lots of new features and a few bugs that get fixed the next day? You must be new around here. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Sat, Mar 21, 2009 at 2:02 PM, Patrick Lauer patr...@gentoo.org wrote: On Saturday 21 March 2009 21:55:20 Ciaran McCreesh wrote: On Sat, 21 Mar 2009 21:53:16 +0100 Patrick Lauer patr...@gentoo.org wrote: Because, as you have noticed before, developers get confused which eapi has which features available. And eapi1 is a superset of eapi0, so we don't have to rewrite tons of things. So? When people do new things, they can move the EAPI forward. That's not a reason to modify existing things. The added complexity of having a dozen eapis does not offer any benefits to the average developer. Limiting the amount of complexity tends to reduce the amount of errors, be it simple developer mistakes or unexpected interaction errors between different EAPIs in the package manager. But you are still talking around the issue. Your logic is that lots of EAPIs mean its harder to write ebuilds. I buy that argument (complexity implies difficult, no problem!) but it is a very generic argument. What about the complexity of many EAPIs are developers having issues with? What can we do to mitigate these problems? Are people using IUSE_DEFAULTS in EAPI0? Are they not bumping the EAPI when adding src_configure to an ebuild? You claim there are all kinds of problems, I want to hear about them so we can fix the tools (aka repoman) to help point out where developers go wrong so they can fix them. Over 80% of the tree is still EAPI0, so deprecating it seems a bad choice at this time, even for a 12-16 month timeline. Introducing a policy encouraging moving things that definitely aren't in the least bit likely to be a system dep on a bump, sure. Making 1 or 2 the default for new packages, sure. But rewriting existing things? That's just an accident waiting to happen. What kind of accident do you expect to happen? The same kind that always happens when lots of ebuilds get changed. ... lots of new features and a few bugs that get fixed the next day? Hey, that sounds quite bad. And maybe some new herd testers? How rude! I don't see the correlation between EAPI bumps and new herd testers. So what technical reason(s) do we have to keep archaic EAPIs around forever? None, luckily this is more than a technical project ;) Patrick
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Sat, 21 Mar 2009 18:37:12 +0100 Patrick Lauer patr...@gentoo.org wrote: To make our lives easier I would suggest deprecating EAPI0 and migrating existing ebuilds over some time to EAPI1 or higher until EAPI0 can be obsoleted at some point in the future. I would set the start of deprecation warnings about 3 months from now and the obsoletion quite a time later, maybe 12 months from now, when a sufficient amount of ebuilds has been migrated. As always, wording is important. I think having too many EAPIs in active use unnecessarily complicates things, such as remembering which features are offered by which EAPIs, etc. I think we should start deprecating EAPI=0 usage *now* with a repoman warning whenever a new ebuild is committed that does not use EAPI=1 or EAPI=2. This warning should encourage use of the newest EAPI, EAPI=2. Obsoleting EAPI=0 should occur when the decision to do so merely codifies the state of the tree (at 90% EAPI0, to pick a number ), at which point the warning would be changed to an error. We could then use a couple of bugdays to convert the remainder of the ebuilds or hand them over to treecleaners if it's just unmaintained cruft. In a year or so, we could change the repoman warning to trigger with EAPI=1 also and make it point to EAPI=3 as the EAPI-of-choice. Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to think about, but since it has some changes like adding src_prepare migration would not be as trivial. So I'd prefer keeping it around a bit longer. Comments? We need to make this a part of the EAPI-upgrade process that whenever a new EAPI is added, we consider including another EAPI in the repoman warning. My hope is that at some point in the future (4 years?), we'll be able to cut out some of the ugly phase hacks we have in many eclasses that had EAPI=2 grafted onto them. /loki_val
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Saturday 21 March 2009 22:26:41 Alec Warner wrote: Introducing a policy encouraging moving things that definitely aren't in the least bit likely to be a system dep on a bump, sure. Making 1 or 2 the default for new packages, sure. But rewriting existing things? That's just an accident waiting to happen. What kind of accident do you expect to happen? The same kind that always happens when lots of ebuilds get changed. ... lots of new features and a few bugs that get fixed the next day? Hey, that sounds quite bad. And maybe some new herd testers? How rude! I don't see the correlation between EAPI bumps and new herd testers. Well, ciaran said that the same thing happens that always happens when lots of ebuilds get changed. Last time I saw that happen (think KDE4) we got some nice herd testers plus a new dev or two, so I am confused too. Maybe ciaran can explain what he meant to say so we don't have to come to unexpected conclusions (that would actually be a quite nice change to the average discussion - saying what you mean instead of hinting at star constellations and the importance of meat loaf) So what technical reason(s) do we have to keep archaic EAPIs around forever? None, luckily this is more than a technical project ;) Stop confusing me, antarus, I thought you were against removing eapi0 and now you support the removal? ;) Anyway. Most of the porting effort (assuming no other issues sneaking in) would be adding a EAPI=1 line to ebuilds, which could be done lazily on version bumps. There's no rush to get it killed now now now, but in a year we might be at EAPI 5, and then I don't want to be the one writing the docs that split apart what features are where and what syntax is valid and all that. So phasing out eapi0 would be an obvious step towards making things simpler for those of us that don't enjoy studying lists and tables ... Patrick
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Sat, 21 Mar 2009 22:51:11 +0100 Patrick Lauer patr...@gentoo.org wrote: The same kind that always happens when lots of ebuilds get changed. ... lots of new features and a few bugs that get fixed the next day? Hey, that sounds quite bad. And maybe some new herd testers? How rude! I don't see the correlation between EAPI bumps and new herd testers. Well, ciaran said that the same thing happens that always happens when lots of ebuilds get changed. Last time I saw that happen (think KDE4) we got some nice herd testers plus a new dev or two, so I am confused too. And a massive amount of breakage, some of which still isn't fixed, yes. Have a look at bugzilla sometime. Anyway. Most of the porting effort (assuming no other issues sneaking in) would be adding a EAPI=1 line to ebuilds, which could be done lazily on version bumps. There's no rush to get it killed now now now, but in a year we might be at EAPI 5, and then I don't want to be the one writing the docs that split apart what features are where and what syntax is valid and all that. Fortunately, you won't be. As the person who probably will be, I can assure you that killing off EAPI 0 won't help in the slightest. It won't mean we can remove all mention of EAPI 0 from the documentation, since package managers need to support EAPIs indefinitely for uninstalls. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Sat, Mar 21, 2009 at 2:51 PM, Patrick Lauer patr...@gentoo.org wrote: On Saturday 21 March 2009 22:26:41 Alec Warner wrote: Introducing a policy encouraging moving things that definitely aren't in the least bit likely to be a system dep on a bump, sure. Making 1 or 2 the default for new packages, sure. But rewriting existing things? That's just an accident waiting to happen. What kind of accident do you expect to happen? The same kind that always happens when lots of ebuilds get changed. ... lots of new features and a few bugs that get fixed the next day? Hey, that sounds quite bad. And maybe some new herd testers? How rude! I don't see the correlation between EAPI bumps and new herd testers. Well, ciaran said that the same thing happens that always happens when lots of ebuilds get changed. Last time I saw that happen (think KDE4) we got some nice herd testers plus a new dev or two, so I am confused too. Maybe ciaran can explain what he meant to say so we don't have to come to unexpected conclusions (that would actually be a quite nice change to the average discussion - saying what you mean instead of hinting at star constellations and the importance of meat loaf) So what technical reason(s) do we have to keep archaic EAPIs around forever? None, luckily this is more than a technical project ;) Stop confusing me, antarus, I thought you were against removing eapi0 and now you support the removal? ;) Editing 2 ebuilds is not 'technical' in nature, its grunt work. It is a social problem, not a technical one. I also haven't stated my support in either direction since you have provided no specific arguments as to why we should do this; there is nothing to argue against. Anyway. Most of the porting effort (assuming no other issues sneaking in) would be adding a EAPI=1 line to ebuilds, which could be done lazily on version bumps. There's no rush to get it killed now now now, but in a year we might be at EAPI 5, and then I don't want to be the one writing the docs that split apart what features are where and what syntax is valid and all that. Or we might be at EAPI 3; we have no EAPI roadmap and I don't like guessing. Again I'm looking for specifics here. You are asking the community to do a lot of work for relatively little gain; because you haven't specified what the gain is. So I ask again What specific problems does this solve? So phasing out eapi0 would be an obvious step towards making things simpler for those of us that don't enjoy studying lists and tables ... Patrick
Re: [gentoo-dev] RFC: Deprecating EAPI0
Patrick Lauer wrote: Hi all, with the discussion about EAPI3 we have now 4 (or 7, depending on how you count them ;) ) EAPIs available or almost available. This is getting quite confusing. To make our lives easier I would suggest deprecating EAPI0 and migrating existing ebuilds over some time to EAPI1 or higher until EAPI0 can be obsoleted at some point in the future. I would set the start of deprecation warnings about 3 months from now and the obsoletion quite a time later, maybe 12 months from now, when a sufficient amount of ebuilds has been migrated. Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to think about, but since it has some changes like adding src_prepare migration would not be as trivial. So I'd prefer keeping it around a bit longer. Comments? Patrick While there definitely arguments for deprecating EAPIs, I would suggest caution. A low number of active EAPIs can make life easier for developers, but it can also make life harder for some users. There are still users coming to the forums upgrading systems which only understand EAPI 0. I accept that Gentoo is certainly a relatively fast moving distro, but I think that developers also do need to consider users who have systems that are currently just working and may not upgrade often (once a year or even less). As such, I would suggest that forcing a move to the most recent stable EAPI is possibly unwise. I believe that forcing EAPIs to move forward at too quick a pace will cause more issues for these users. An answer to this could be to set a standard for the minimum time between upgrades - for example, 1 year - and ensure that users with anything that old can atleast upgrade portage and its dependencies to the minimum required versions without major issues. I understand that this may cause extra work in some respects, but if such a standard is set and documented then it will help users (admins) by giving them a set frequency at which they must upgrade at least the package manager, if not @system. Secondly, it was suggested that a project to upgrade all ebuilds in the tree from EAPI 0 could bring new developers, offering KDE4 as an example. I would offer caution on this assumption. KDE4 was not simply about upgrading ebuilds, but about users (contributors) and developers being able to install and test packages they wanted to install and test. I can not realistically see such an effort being asserted in the name of simply deprecating EAPIs. Yes, breakage occurred, but this was as far as I can see a complete rewrite of the KDE packaging from scratch. As such I would suggest that a certain level of breakage was to be expected. I would also suggest that the speed at which bugs are being fixed may be more of an indicator of lack of man power than anything else, and that the situation could be improved by looking at expending more effort on encouraging contributions and ultimately recruiting developers. I realize that getting people to expend effort on non-coding work can be difficult, but I think that ultimately the effort expended will be repaid in terms of extra contributions. In general, I would have to agree with those who believe there are currently better ways to expend effort within Gentoo. As such I would suggest that at most, EAPI deprecation only applies to new packages and version bumps. AllenJB
