Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)
On Mon, 01 Sep 2008 08:08:07 -0700 Zac Medico <[EMAIL PROTECTED]> wrote: > > Does this (and previous similar threads) suggestion means that > > portage will not support GLEP 54? Or how it'll be related with said > > glep? > > It seems like GLEP 54 is intended to fill a similar gap in the > ebuild metadata. With PROPERTIES=live, it doesn't seem like GLEP 54 > will be much use since it seems like you can achieve essentially the > same results by using PROPERTIES=live together with the existing > version suffixes such as _pre and _p (to control ordering). Er, no you can't. There is no way of using existing version components to get the correct ordering. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Volkov wrote: > В Сбт, 23/08/2008 в 13:39 -0700, Zac Medico пишет: >> Please consider a PROPERTIES=live value that, when set in an ebuild, >> will serve to indicate that the ebuild will use some form of "live" >> source code that may vary each time that the package is installed. > > Does this (and previous similar threads) suggestion means that portage > will not support GLEP 54? Or how it'll be related with said glep? > It seems like GLEP 54 is intended to fill a similar gap in the ebuild metadata. With PROPERTIES=live, it doesn't seem like GLEP 54 will be much use since it seems like you can achieve essentially the same results by using PROPERTIES=live together with the existing version suffixes such as _pre and _p (to control ordering). - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAki8BVYACgkQ/ejvha5XGaO8FACfUxmb1cchCxyiaA8Www1cYahG wcMAn3H2vlh/SMQQFC1BLp9H+e+Nz3aj =FdPD -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Add support for package.keywords in profiles?
В Пнд, 25/08/2008 в 11:40 -0700, Zac Medico пишет: > Peter Volkov wrote: > > It's good feature for overlays, but I think we should avoid this in > > portage tree as having same information in two places can be avoided in > > this case: it's better and not so hard to write tool which will keyword > > packages based on package.keywords file and new keywords could be chosen > > like GLEP 22 suggests. > > I'm not sure I understand the purpose of this tool that you mention. > Are you saying that package.keywords might be a good thing to use > initially and then later, if we choose (maybe we will or maybe we > won't), we have the option do an automated migrations of specific > profiles to separate keywords like those in GLEP 22? Yes. And by initially I meant overlays outside Gentoo tree and then this tool could be useful during merge with portage tree. > The question of whether or not we should implement package.keywords > for the sake of private profiles should be considered separately from > the question of whether or not we choose a policy to allow the use of > package.keywords in one or more of our official gentoo profiles. Ok, then my answer is yes. With best regards, -- Peter.
Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)
В Сбт, 23/08/2008 в 13:39 -0700, Zac Medico пишет: > Please consider a PROPERTIES=live value that, when set in an ebuild, > will serve to indicate that the ebuild will use some form of "live" > source code that may vary each time that the package is installed. Does this (and previous similar threads) suggestion means that portage will not support GLEP 54? Or how it'll be related with said glep? -- Peter.
Re: [gentoo-dev] Re: Re: Re: [RFC] What features should be included in EAPI 2?
В Чтв, 21/08/2008 в 19:26 -0700, Alec Warner пишет:
> src_prepare is a logically distinct action (maybe if we called it
> src_patch it would be clearer?)
We are not only patching sources there but modify them by other means
too (like sed or find .. rm \{\};). So src_prepare is the name which
better reflects intention.
В Втр, 19/08/2008 в 12:12 +0100, Steve Long пишет:
> Besides saving one line of typing, what is the benefit of adding this
> new phase?
Although this disagreement is already closed I'd like to point that
sometimes it's more than one line:
http://overlays.gentoo.org/dev/pva/browser/x11-apps/gxneur/gxneur-0.9.0_p106.ebuild
Also... well Ryan already made the point I was going to write. :)
--
Peter.
[gentoo-dev] Monthly Gentoo Council Reminder for September
This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Keep in mind that every GLEP *re*submission to the council for review must first be sent to the gentoo-dev mailing list 7 days (minimum) before being submitted as an agenda item which itself occurs 7 days before the meeting. Simply put, the gentoo-dev mailing list must be notified at least 14 days before the meeting itself. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/
