Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)
On Sat, 23 Aug 2008 13:39:58 -0700 Zac Medico [EMAIL PROTECTED] wrote: Do the name and definition of this PROPERTIES=live value seem good? Would anybody like to discuss any changes to the name, definition, or both? Not sure if 'live' is really the best choice here, as many things also apply to e.g. automated daily/nightly snapshots/builds that might also be useful to support. Maybe 'unversioned' is more accurate. Marius
Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)
Marius Mauch wrote: Not sure if 'live' is really the best choice here, as many things also apply to e.g. automated daily/nightly snapshots/builds that might also be useful to support. Maybe 'unversioned' is more accurate. I think the most important thing to convey with this property is that the source code can change at any time, since it is pulled live from upstream. unversioned doesn't really imply this - it makes it sound like it simply has no version. Maybe something akin to volatile would work, but I still like live, personally. -Joe
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] [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] 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)
On 13:39 Sat 23 Aug , Zac Medico wrote: 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. The intention is for PROPERTIES=live to have a relatively pure and simple meaning. Therefore, the definition is intentionally more narrow than the definitions previously suggested for the related RESTRICT=live [1] and PROPERTIES=live-sources [2] values. In the future we may add additional (orthogonal) properties to represent other things like locking [3]. Here's what I'd like to see from this whole PROPERTIES discussion. - Are the PROPERTIES more fine-grained than they need to be? - Are the common use cases specifiable by a single PROPERTIES setting that may actually do multiple things on the back end? If there's actually reasons for these things to be very narrow, I'd like to see easily usable meta-properties that let people easily say something like I've got a live CVS ebuild without specifying 20 different PROPERTIES. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpMMyb7L33ja.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: On 13:39 Sat 23 Aug , Zac Medico wrote: 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. The intention is for PROPERTIES=live to have a relatively pure and simple meaning. Therefore, the definition is intentionally more narrow than the definitions previously suggested for the related RESTRICT=live [1] and PROPERTIES=live-sources [2] values. In the future we may add additional (orthogonal) properties to represent other things like locking [3]. Here's what I'd like to see from this whole PROPERTIES discussion. - Are the PROPERTIES more fine-grained than they need to be? - Are the common use cases specifiable by a single PROPERTIES setting that may actually do multiple things on the back end? Sure, we can add addition properties that have compound meanings. However, I'm pretty satisfied with the pure and simple form that I've suggested for the live, virtual, and interactive properties. Their purity makes them narrow in a way, but also broad in the sense that they will usable for a maximum number of ebuilds without any deviation from the official meaning. If there's actually reasons for these things to be very narrow, I'd like to see easily usable meta-properties that let people easily say something like I've got a live CVS ebuild without specifying 20 different PROPERTIES. For a cases like this, we can define a live-cvs property that implies the live property. By defining compound properties in this way, we can avoid things like PROPERTIES=live live-cvs since live-cvs alone will also imply live. As such, it would be redundant to set PROPERTIES=live live-cvs when PROPERTIES=live-cvs would have identical meaning. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiy8AgACgkQ/ejvha5XGaOnuQCg7up9Pw0nIgtg8GvKgTj2KHKn VKwAoJ5xfKpaYEn8Z5u1ly7ELHoh+t3N =4tZZ -END PGP SIGNATURE-
[gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, 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. The intention is for PROPERTIES=live to have a relatively pure and simple meaning. Therefore, the definition is intentionally more narrow than the definitions previously suggested for the related RESTRICT=live [1] and PROPERTIES=live-sources [2] values. In the future we may add additional (orthogonal) properties to represent other things like locking [3]. Since there is no direct correspondence between what PROPERTIES=live represents and any existing ebuild metadata (though there is some limited correspondence with various INHERITED values), addition of PROPERTIES=live will provide metadata that is useful in at least a few ways: * Make the @live-rebuild package set [4] more accurate. * Make repoman's LIVEVCS.stable check more accurate. * Add exemptions to repoman's KEYWORDS.missing and KEYWORDS.dropped checks. Do the name and definition of this PROPERTIES=live value seem good? Would anybody like to discuss any changes to the name, definition, or both? [1] http://archives.gentoo.org/gentoo-dev/msg_164fd8d5d513121ab772509d06a7b27a.xml [2] http://archives.gentoo.org/gentoo-dev/msg_187585c5d49b69034183719ff473710d.xml [3] http://archives.gentoo.org/gentoo-dev/msg_7b5e4610fe1802149960ae5365bdedce.xml [4] http://planet.gentoo.org/developers/zmedico/2008/07/31/live_rebuild_package_set - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiwdZ0ACgkQ/ejvha5XGaMlTwCdEqg6mpLAn8r/6JCfaVzQpBaC xMMAn3wGpli8sAuOYLf2Se4NHtrA0mC6 =6Mco -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)
Zac Medico wrote: Do the name and definition of this PROPERTIES=live value seem good? Would anybody like to discuss any changes to the name, definition, or both? ++ -Joe
Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)
Zac Medico wrote: The intention is for PROPERTIES=live to have a relatively pure and simple meaning. Ok. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico wrote: | Hi everyone, | | 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. | The intention is for PROPERTIES=live to have a relatively pure and | simple meaning. Therefore, the definition is intentionally more | narrow than the definitions previously suggested for the related | RESTRICT=live [1] and PROPERTIES=live-sources [2] values. In the | future we may add additional (orthogonal) properties to represent | other things like locking [3]. | | Since there is no direct correspondence between what PROPERTIES=live | represents and any existing ebuild metadata (though there is some | limited correspondence with various INHERITED values), addition of | PROPERTIES=live will provide metadata that is useful in at least a | few ways: | | * Make the @live-rebuild package set [4] more accurate. | | * Make repoman's LIVEVCS.stable check more accurate. | | * Add exemptions to repoman's KEYWORDS.missing and KEYWORDS.dropped |checks. Although an exemption to KEYWORDS.missing is in itself already a good progress, imho it would be even better if repoman, pcheck and other QA testing tools complained if there were any keywords set for an ebuild with PROPERTIES=live. | Do the name and definition of this PROPERTIES=live value seem good? | Would anybody like to discuss any changes to the name, definition, | or both? Seems a good idea. Thanks for all the work on the good proposals you've submitted lately to the dev ml. | [1] | http://archives.gentoo.org/gentoo-dev/msg_164fd8d5d513121ab772509d06a7b27a.xml | [2] | http://archives.gentoo.org/gentoo-dev/msg_187585c5d49b69034183719ff473710d.xml | [3] | http://archives.gentoo.org/gentoo-dev/msg_7b5e4610fe1802149960ae5365bdedce.xml | [4] | http://planet.gentoo.org/developers/zmedico/2008/07/31/live_rebuild_package_set - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiwksAACgkQcAWygvVEyAJHEgCeKrJF4tVLd7etilp9JdbQTyCq BZUAmweZ+nbSVwj+kpeQWJb4MdVUkN15 =+wSW -END PGP SIGNATURE-
