Re: [gentoo-dev] Re: EAPI 2 must die
Am 06.06.19 um 17:28 schrieb Anthony G. Basile: > Didn't we have some "archive" for old ebuilds? Maybe we can move > it there. What about an overlay for this purpose? Its like in real life they come into life and leave the same way... Despite that, I usually dig in the git repository when I look for deleted files et.al. like described here https://stackoverflow.com/questions/7203515/git-how-to-find-a-deleted-file-in-the-project-commit-history signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: EAPI 2 must die
On 6/6/19 3:34 AM, Luca Barbato wrote: > On 06/06/2019 09:05, Matt Turner wrote: >> On Wed, Jun 5, 2019 at 11:39 PM Agostino Sarubbo wrote: >>> >>> On giovedì 6 giugno 2019 08:25:54 CEST Luca Barbato wrote: Anybody has hardware to test it? >>> >>> I can do it on timberdoodle. >> >> The issue is that the package is for "OldWorld" Macs (like 20+ years >> old). We recently dropped the bootloader, sys-boot/quik, so I think >> we'd be fine to drop sys-apps/powerpc-utils as well. >> > > Exactly :) > > I'm fine with treecleaning it. > > lu > Lol! I still have some OldWorld Macs, but I'm okay with tree cleaning it. Didn't we have some "archive" for old ebuilds? Maybe we can move it there. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
[gentoo-dev] Re: EAPI 2 must die
On 06/06/2019 09:05, Matt Turner wrote: On Wed, Jun 5, 2019 at 11:39 PM Agostino Sarubbo wrote: On giovedì 6 giugno 2019 08:25:54 CEST Luca Barbato wrote: Anybody has hardware to test it? I can do it on timberdoodle. The issue is that the package is for "OldWorld" Macs (like 20+ years old). We recently dropped the bootloader, sys-boot/quik, so I think we'd be fine to drop sys-apps/powerpc-utils as well. Exactly :) I'm fine with treecleaning it. lu
[gentoo-dev] Re: EAPI 2 must die
On Wed, Jun 5, 2019 at 11:39 PM Agostino Sarubbo wrote: > > On giovedì 6 giugno 2019 08:25:54 CEST Luca Barbato wrote: > > Anybody has hardware to test it? > > I can do it on timberdoodle. The issue is that the package is for "OldWorld" Macs (like 20+ years old). We recently dropped the bootloader, sys-boot/quik, so I think we'd be fine to drop sys-apps/powerpc-utils as well.
[gentoo-dev] Re: EAPI 2 must die
On giovedì 6 giugno 2019 08:25:54 CEST Luca Barbato wrote: > Anybody has hardware to test it? I can do it on timberdoodle. Agostino
[gentoo-dev] Re: EAPI 2 must die
On 06/06/2019 07:06, Andreas K. Huettel wrote: Hi all, for the package maintainers among you, here's the list of remaining EAPI=2 packages. Please help getting the number down to zero soon!!! Cheers, Andreas sys-apps/powerpc-utils-1.1.3.18-r2 This is ancient in many different ways :) Anybody has hardware to test it? lu
[gentoo-dev] Re: EAPI 2 policy for portage tree
Olivier Crête [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 08 Dec 2008 19:43:42 -0500: I'm not suggesting waiting any longer, just not pushing ebuilds into the tree until we have a stable enough version of portage that handles them (and if we do, then lets mark it as stable..). FWIW this ~arch user's perspective: AFAIK, the policy is now that no EAPI is allowed to pass where the corresponding version of portage is, stability-wise. That means, if a portage supporting that EAPI is only available in overlays, ebuilds/ eclasses supporting it must also remain in overlays -- they can't be added to the tree. (It's worth mentioning here that overlays aren't restricted to portage features at all, some use features not in portage, period, only in one of the other PMs.) Once a portage supporting that EAPI is in the tree, hard-masked for testing, ebuilds using it may also be in the tree, but also hard-masked. Once a portage supporting that EAPI is in ~arch for testing, then ebuilds using it can likewise move to ~arch for testing, but they can't go stable yet. Only after a portage supporting a particular EAPI is stable can an ebuild requiring that EAPI stabilize as well. Note that in the above there's NOTHING stating that an ebuild that's in ~arch for testing, cannot switch to an EAPI only likewise in ~arch for testing. It's quite possible that such an ebuild still in ~arch will be found to work better with features only in a new EAPI, and it's quite legitimate in my opinion to change the ~arch ebuild (still testing, remember) to require it, as long as a version of portage with support is already in ~arch as well. Of course, by doing so the maintainer accepts that he may not stabilize that ebuild until the supporting portage goes stable as well, but if that's the case, there should be nothing blocking an existing ~arch ebuild from being modified to require an existing ~arch portage, both of them still being in ~arch testing, after all. If people want to play with a few ~arch packages here or there, while most of the system stays arch/stable, fine, but the choice and results of the choice should both be their responsibility. Maintaining devs shouldn't have to worry about changing an ebuild that after all is still in ~arch, if they judge it will ultimately make for a more stable ebuild headed into stable. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
I don't want to be the guy that kicks people off lists; but I will do it; so keep the thread on topic[0] and be nice[1]. I know everyone here is capable of that. Feel free to sling the personal crap comments somewhere more appropriate (such as a personal diary, blog, or in verbal complaints to a spouse or drinking buddy.) Remember that text is hard to communicate through and regardless of any intentions, people are judged by how they are perceived and 'helpful' intentions may not come off quite as helpful as some would like; chose your words carefully. Consider this your first and last warning from Userrel. -Alec [0] Subject: Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses [1] http://www.gentoo.org/proj/en/council/coc.xml
[gentoo-dev] Re: EAPI-2 and src_configure in eclasses
Alec Warner [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 10 Oct 2008 00:17:14 -0700: Consider this your first and last warning from Userrel. FWIW... at least on gmane, that appears as a response to aballier (gentoo dev), with references headers indicating the same thing, but given that (1) there was no attribution or quote so it's not possible to say who it was intended for directly, (2) I didn't see what was offensive in his post, and (3) that the warning was from userrel not devrel, I believe the warning was intended for someone other than the direct parent (my grandparent) poster. IOW, aballier may be very confused right about now... I know I was but at least it's not my posts in the balance like his appear to be, while someone else (my public attempt at a guess who wouldn't help) may be missing a warning they need to see (tho hopefully they got the message in any case). -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
On Fri, Oct 10, 2008 at 5:41 AM, Duncan [EMAIL PROTECTED] wrote: Alec Warner [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 10 Oct 2008 00:17:14 -0700: Consider this your first and last warning from Userrel. FWIW... at least on gmane, that appears as a response to aballier (gentoo dev), with references headers indicating the same thing, but given that (1) there was no attribution or quote so it's not possible to say who it was intended for directly, (2) I didn't see what was offensive in his post, and (3) that the warning was from userrel not devrel, I believe the warning was intended for someone other than the direct parent (my grandparent) poster. IOW, aballier may be very confused right about now... I know I was but at least it's not my posts in the balance like his appear to be, while someone else (my public attempt at a guess who wouldn't help) may be missing a warning they need to see (tho hopefully they got the message in any case). Assume the warning was for the whole list; I just replied to the last message in the thread; blame gmail ;) -Alec -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
I don't quite see how that deals with an eclass calling econf in its exported src_compile? Seems like EAPI versioning for eclasses (with implicit 0 only) is more what you're after for that issue (so the PM could suppress src_configure if src_compile is going to resolve to an EAPI-0 eclass function, although the inheritance stack might prove problematic.) I don't know of any way for the pm to detect if the eclass supports given eapi or not, and even less if exported src_compile will be eapi-2 aware or not. Having to die for an unsupported EAPI seems like the wrong approach; if it's not going to work the PM shouldn't source it. If it can be made to work by filtering certain functions, that's doable. I tend to see dying for an unsupported eapi as eclass versioning for the poor people but that's the only thing we can do atm afaik. For now, all eapi are backward compatible wrt to sourcing so that's not really an issue to source an eapi-0 eclass withing an eapi-2 ebuild. I think there has been a discussion on eclasses vs eapi before and the outcome was that eclasses should add hacky checks for eapi; which means to me we'll have to adjust those hacky checks for each new eapi. However, for now, not dying allows workarounds like: http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-video/ogmrip/ogmrip-0.12.2.ebuild?view=markup but I don't consider it very pretty. In the worst case, an ebuild switching to EAPI will require eclass maintenance; this is where the separation of elibs (useful code) and eclasses (template ebuilds) would be useful, although that needs versioning too. The problem will remain for this new definition of eclasses; glad to see you're volunteering to fix every single eclass that exports a src_compile/unpack function for eapi-2 :) If by template ebuilds you mean the EXPORT_FUNCTIONS line and some deps, then I dont see the difference between eapi versioning for eclasses and a switch/case for each eapi in the unversioned eclass. Note that useful code can differ upon eapi (I'm thinking about has_version checks). Regards, Alexis. signature.asc Description: PGP signature
[gentoo-dev] Re: EAPI-2 and src_configure in eclasses
Alexis Ballier wrote: Indeed; different names could be given to different implementations of the same thing, but that might completely kill the point of abstracting it. Maybe eclasses should die on unknown eapi; the fact is I really hate the current way it's done when switching an ebuild to EAPI-2 which uses an eclass that exports src_compile; most eclasses don't special case eapi-2 yet and we end up running econf twice at best. I fear that'll be the same with eapi-3, eapi-4, etc. (supposing that they'll support src_configure too) An EXPORT_FUNCTIONS ignoring any function its doesn't know for its eapi would help too. Ciaran McCreesh [EMAIL PROTECTED] wrote: An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place checking for eclass screwups... yes; that's just a matter of choice though, but for eclasses it's probably not luxury. Well it's simple enough to check (and give a QA warning) for unknown functions; adding a check for a specific string prefix (or to exclude a certain subset) in EXPORT_FUNCTIONS (based on current EAPI) is simple enough too. Is that what you mean? The behaviour to trigger could change eg for debug mode, or a repoman check. I don't quite see how that deals with an eclass calling econf in its exported src_compile? Seems like EAPI versioning for eclasses (with implicit 0 only) is more what you're after for that issue (so the PM could suppress src_configure if src_compile is going to resolve to an EAPI-0 eclass function, although the inheritance stack might prove problematic.) Having to die for an unsupported EAPI seems like the wrong approach; if it's not going to work the PM shouldn't source it. If it can be made to work by filtering certain functions, that's doable. In the worst case, an ebuild switching to EAPI will require eclass maintenance; this is where the separation of elibs (useful code) and eclasses (template ebuilds) would be useful, although that needs versioning too.
Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
On Tue, 07 Oct 2008 17:07:21 +0100 Steve Long [EMAIL PROTECTED] wrote: It's illegal, according to PMS. It also won't work with Paludis, since phase function definitions aren't made available until just before that phase executes (there is a reason for this -- it provides us with a way of identifying whether a package has a particular phase or not). That seems a bit implementation-specific; how one alternative package manager generates that metadata isn't important (though it does seem odd that you think it has to be done at that point) nor should it get in the way. The whole point of PMS is that it provides a way to avoid relying upon implementation specific things. There are currently no packages that rely upon calling phase functions in the wrong place, and there are good reasons a package manager might want to avoid implementing things in a way such that doing so is legal, so we don't allow it. Also, I don't think it has to be done at that point. I think it's convenient to do it at that point, and when combined with several other reasons doing it that way is the best option. Strange how you repeatedly seem to pop up in favour of doing whatever you think will cause most inconvenience to Paludis, though... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: EAPI-2 and src_configure in eclasses
Ciaran McCreesh wrote: On Sun, 5 Oct 2008 17:38:11 +0200 Ulrich Mueller [EMAIL PROTECTED] wrote: By the way, do we really want to special case eapi-2 in every eclass ? That's lot of code duplication and will get even worse when we'll reach eapi-42. That would have been cool to have a pm function that tells has my eapi foo support but that sort of bites its tail that way. Hm, what about: [ $(type -t src_configure) == function ] EXPORT_FUNCTIONS src_configure Or is this too fragile or trying to be too clever? It's illegal, according to PMS. It also won't work with Paludis, since phase function definitions aren't made available until just before that phase executes (there is a reason for this -- it provides us with a way of identifying whether a package has a particular phase or not). That seems a bit implementation-specific; how one alternative package manager generates that metadata isn't important (though it does seem odd that you think it has to be done at that point) nor should it get in the way.
Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
On Tue, Oct 07, 2008 at 05:07:21PM +0100, Steve Long wrote: Ciaran McCreesh wrote: On Sun, 5 Oct 2008 17:38:11 +0200 Ulrich Mueller [EMAIL PROTECTED] wrote: By the way, do we really want to special case eapi-2 in every eclass ? That's lot of code duplication and will get even worse when we'll reach eapi-42. That would have been cool to have a pm function that tells has my eapi foo support but that sort of bites its tail that way. Hm, what about: [ $(type -t src_configure) == function ] EXPORT_FUNCTIONS src_configure Or is this too fragile or trying to be too clever? It's illegal, according to PMS. It also won't work with Paludis, since phase function definitions aren't made available until just before that phase executes (there is a reason for this -- it provides us with a way of identifying whether a package has a particular phase or not). That seems a bit implementation-specific; how one alternative package manager generates that metadata isn't important (though it does seem odd that you think it has to be done at that point) nor should it get in the way. Actually both alternative PM's do this now (=pkgcore-0.4.7.9), although in pkgcore's case the default phase functions are installed after sourcing rather then at the time of invocation. Long term, this is the correct way to go imo- the downside to it is that a common sourcing env needs be defined at some point (newdepend, newrdepend, etc) to avoid any question of what's available. ~brian pgplTnmKBbhpJ.pgp Description: PGP signature
[gentoo-dev] Re: EAPI-2
Carsten Lohrke [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sun, 14 Sep 2008 16:21:03 +0200: What I do strongly oppose is changing the meaning of the '!' symbol, as blockers, which should remain real blockers will not be adjusted by us, when changing an ebuild to EAPI 2++ in every case, since we're humans after all. So, if you implement this, keep '!' as is and find another symbol for these soft blockers. I had wondered about that, but since no devs were bringing it up, I thought it must not be as big a deal as I had thought. Now one has. ~ * A new src_prepare phase function is called after src_unpack. ~ * The old src_compile phase function is split into separate ~ src_configure and src_compile fuctions. All I do see is more complexity, but no real benefit. This is from a user's perspective, but there's a significant benefit to people with poor hardware. I began my Gentoo journey with memory that only marginally supported the bandwidth it was rated for and had to live with the related crashes, reboots, and restart-the-emerges. As such, I quickly learned the benefits of ccache and ebuid's step-by-step process. I sure could have used a separate configure step at that point! With configure separate, it wouldn't have had to be redone each time I crashed and had to restart. I could and often did re-issue the half completed make commands by hand, letting the package's own build system pick up where it left off, but that didn't fill in the blanks in portage's package data, and I had to reissue the ebuild compile command to do so. Only compile meant reconfigure too, which of course touched the various makefiles, forcing a recompile of the whole thing again -- and another chance at a crash while doing so. If configure had been a separate stage, all those makefiles wouldn't have been touched and the package's build system would have seen that everything was built already, which would have saved me an AWFUL lot of trouble. The unpack/prepare split wouldn't have been quite as useful as that was generally fast and crash resistant enough I didn't have problems with it, but it won't hurt, and would make user modification of existing ebuilds slightly easier. As for the dev perspective, based on my ebuild hacking to date, I can see a significant benefit for the two spits there as well. That the new phases match natural steps in most upstream package build processes where Gentoo formerly merged steps makes it that much simpler to trace down bugs when something goes wrong. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 14:20:03 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Santiago M. Mola wrote: Upstream clearly states that a gmp build which tests have failed shouldn't be used. I bet they deny support for users who fail to follow that indication ;-) gmp isn't a key component if you aren't using math/sci applications using it. You may point openssl as something you may want to have a round of checks before is too late, same for openssh. Minor nit: GMP is a requirement to build GCC =4.3, so it'll be a key component soon enough. Changing the default features would just at best have people that do not care switch to -test, people that care already about that won't be affected and just create an annoyance. Putting it in an eapi makes not much sense as well since you may change the defaults as you wish since they aren't causing incompatibilities. To sum up: - having the test feature on by default isn't good for anybody but paranoids and lazy developers, paranoids have that already on, lazy developers will switch it off for them and let people do the automated test for them. - having that mandated by the eapi doesn't have sense since it doesn't change anything by itself. Fully in agreement. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 01:42:34 +0200
Bo Ørsted Andresen [EMAIL PROTECTED] wrote:
Err.. Maybe this could have been phrased better but then I did expect
you would look at the bug before commenting. The idea is to enable
tests by default in EAPI 2 and beyond and let them stay off by
default in EAPI 0 and 1. This way devs who want to use EAPI 2 will
either have to fix their tests or RESTRICT them. Doing it this way
avoids the issue of having to fix the whole tree all at once. Users
can still choose not to go with the default.
if people are just going to RESTRICT tests when they fail (and they
will, because it's a hell of a lot easier than actually fixing them),
what's the point of having a testsuite at all? and once a testsuite is
restricted, it'll stay restricted even if upstream fixes the problem
because no one will bother checking. the time needed for
testsuites can be substantial. (auto{make,conf} can take half an hour
to run the tests on a fast machine (compared to the total compile
and install time of 10 seconds). the build time for gcc triples.) they
can pull in a large number of dependencies. etc, etc.
as i mentioned on the bug, i'd like to see something like
FEATURES=dev that would enable tests by default, turn on those QA
source code warnings, maybe some of the stuff from stricter, and other
things that our users don't really need but are important to us.
anyways, just my opinion.
Users can still choose not to go with the default.
so can devs, and they outnumber us. ;)
--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: EAPI-2 - Let's get it started
On Tue, 10 Jun 2008 23:16:04 -0600 Ryan Hill [EMAIL PROTECTED] wrote: if people are just going to RESTRICT tests when they fail (and they will, because it's a hell of a lot easier than actually fixing them), what's the point of having a testsuite at all? and once a testsuite is restricted, it'll stay restricted even if upstream fixes the problem because no one will bother checking. You're assuming that developers are lazy, incompetent and don't care about QA. If this isn't the case, developers will instead fix or remove individual test failures where reasonably possible, and will unrestrict tests when doing version bumps. -- Ciaran McCreesh signature.asc Description: PGP signature
