Re: [gentoo-dev] EAPI-2
On Dienstag, 9. September 2008, Jorge Manuel B. S. Vicetto wrote: > ~ * The meaning of the !atom blocker syntax now implies that > ~ temporary simultaneous installation of conflicting packages is > ~ allowed [3]. > > ~ * A new !!atom blocker syntax is now supported, for use in special > ~ cases in which temporary simultaneous installation of conflicting > ~ packages should not be allowed. I didn't really look into the issues, intended to be resolved with this, but I'm somewhat suspecious that this is merely a hack around inaccurate dependency listing in ebuilds on the one side and Portage's dependency resolver issues on the other. 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. > ~ * 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. Carsten signature.asc Description: This is a digitally signed message part.
[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
Re: [gentoo-dev] EAPI-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carsten Lohrke wrote: > On Dienstag, 9. September 2008, Jorge Manuel B. S. Vicetto wrote: >> ~ * The meaning of the !atom blocker syntax now implies that >> ~ temporary simultaneous installation of conflicting packages is >> ~ allowed [3]. >> >> ~ * A new !!atom blocker syntax is now supported, for use in special >> ~ cases in which temporary simultaneous installation of conflicting >> ~ packages should not be allowed. > > I didn't really look into the issues, intended to be resolved with this, but > I'm somewhat suspecious that this is merely a hack around inaccurate > dependency listing in ebuilds on the one side and Portage's dependency > resolver issues on the other. Well, I'm open to alternative suggestions. Please see the previous email in which I've attempted to explain the reasoning for the given approach [1]. It seems to me that this approach is well suited for solving cases in which temporary simultaneous installation of blocking packages is needed. > 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. Again, please see my previous email on this subject [1]. The reason that I think we should change the meaning of the '!' symbol is that the majority of existing EAPI 0 or 1 blockers appear to fit the new meaning already. So, we'll only have to use the new !!atom syntax for special cases in which temporary simultaneous installation of blocking packages must be explicitly forbidden. >> ~ * 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. My impression is that most people tend to see these as useful extensions despite the slight increases in complexity. > > Carsten [1] http://archives.gentoo.org/gentoo-dev/msg_2551bea5c002093d5bacc26723208d93.xml - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjNR5sACgkQ/ejvha5XGaPR0gCgkiG7H4HZ4ASh/SyLboFGTCix 50EAmwU6WWU3gx5GV+EU1NqRmY+s4fDb =rbQz -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: app-editors/ted
On Fri, Sep 12, 2008 at 10:17:12PM -0500, Jeremy Olexa wrote: > # Jeremy Olexa <[EMAIL PROTECTED]> (13 Sep 2008) > # Masked for removal in 60 days. Multiple issues, broke for some people. > Needs > # maintainer. automagic deps. See bug #154997 > app-editors/ted I've fixed the build and marked myself as maintainer; I don't want to see this gone just yet.
[gentoo-dev] Re: RFC: Glep 55 use case: moving slot to file name
Petteri Räty wrote: > Icedtea has two release tracks. One for the 1.7 OpenJDK code base and > one for the 1.6 code base. They have independent version numbering so > they can have collisions. By moving the slot to the file name we could > have icedtea-1.2:1.6.ebuildN and icedtea-1.2:1.7.ebuildN. This > particular situation can be worked around of course but it might also be > better to keep the slot in the file name any way because I often find > myself needing to know the slot of an ebuild (adjutrix -k of course > already does this for me quite nicely). > Debian-style epochs are a _much_ cleaner solution: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version (eix does quite nicely at displaying slots, too.)
Re: [gentoo-dev] EAPI-2
On Thursday 11 September 2008 21:06:48 Doug Goldstein wrote: > Tobias Scherbaum wrote: > > Luca Barbato wrote: > >> I don't see any problems with it. > > > > +1 > > > > Tobias > > +1 Since this latest version hasn't generated any noticeable disagreement, could the Council please formally vote on it at the next meeting?
Re: [gentoo-dev] EAPI-2
David Leverton kirjoitti: On Thursday 11 September 2008 21:06:48 Doug Goldstein wrote: Tobias Scherbaum wrote: Luca Barbato wrote: I don't see any problems with it. +1 Tobias +1 Since this latest version hasn't generated any noticeable disagreement, could the Council please formally vote on it at the next meeting? Hopefully someone formats it to a real GLEP before that. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI-2
On Sun, 14 Sep 2008 23:51:11 +0300 Petteri Räty <[EMAIL PROTECTED]> wrote: > Hopefully someone formats it to a real GLEP before that. git clone git://git.overlays.gentoo.org/proj/pms.git git diff origin/master..origin/eapi-2 -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2
On Sonntag, 14. September 2008, Zac Medico wrote: > Well, I'm open to alternative suggestions. Please see the previous > email in which I've attempted to explain the reasoning for the given > approach [1]. It seems to me that this approach is well suited for > solving cases in which temporary simultaneous installation of > blocking packages is needed. Thanks for pointing me to it, Zac. I do not pretend to be able to pull the white bunny out of the black hat, presenting you the perfect alternative, especially since you've thought about it a lot more than me. I just feel uncomfortable, having ebuilds overwrite each others files. According to the referenced data, it'll work around a number of issues. The time will show, If real hard blocker issues remain a problem, I guess. > Again, please see my previous email on this subject [1]. The reason > that I think we should change the meaning of the '!' symbol is that > the majority of existing EAPI 0 or 1 blockers appear to fit the new > meaning already. So, we'll only have to use the new !!atom syntax > for special cases in which temporary simultaneous installation of > blocking packages must be explicitly forbidden. Just the majority or pretty much all and the others are easily to find out and moved to EAPI 2, so the point I raised ceases to exist!? I want to share another thought regarding this proposed addtion: !! has the double meaning a) "unmerge the following ebuilds later" and b) "overwriting files of the following ebuilds while merging changes makes them owned by the freshly merged ebuild" so we have one symbol denoting two different commands, which could find use independently. Moreso, if we add more of these symbols to express something different, our syntax may look almost like Lisp in the end: use? ( ! ( X ( Y ( || ( ( foo bar ) baz ) ) ) ) ) ) Looks ugly, doesnt it? How about using two symbols for !! and having the possibility to aggreagate them, e.g. use? ( !XY||: ( ( foo bar ) baz ) ) instead?! Carsten signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI-2
On 21:55 Sun 14 Sep , Ciaran McCreesh wrote: > On Sun, 14 Sep 2008 23:51:11 +0300 > Petteri Räty <[EMAIL PROTECTED]> wrote: > > Hopefully someone formats it to a real GLEP before that. > > git clone git://git.overlays.gentoo.org/proj/pms.git > git diff origin/master..origin/eapi-2 Ciaran, could you merge eapi-differences-summary into eapi-2 to address Petteri's concern about specifying EAPI differences in one place? Or just merge both of them into master. It would also be extremely useful to have some way to discriminate the status of each EAPI (perhaps in the same appendix): approved, draft, or in progress. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgp2dusNrPP73.pgp Description: PGP signature
