[gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)

[gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)

[Zac Medico]

-----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)

[Joe Peterson]

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)

[Luca Barbato]

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)

[Jorge Manuel B. S. Vicetto]

-----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-----

Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)

[Zac Medico]

-----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-----

Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)

[Peter Volkov]

В Сбт, 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)

[Zac Medico]

-----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)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

On Mon, 01 Sep 2008 08:08:07 -0700
Zac Medico <zmedico@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)

[Marius Mauch]

On Sat, 23 Aug 2008 13:39:58 -0700
Zac Medico <zmedico@gentoo.org> 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)

[Joe Peterson]

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