-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi everyone,
As a substitute for the previously discussed RESTRICT=live value[1],
I'd now like you to consider an equivalent PROPERTIES=live-sources
setting. By specifying PROPERTIES=live-sources, an ebuild will be
able to indicate that it uses src_unpack() to download sources from
some type of live repository such as cvs, darcs, git, mercurial, or svn.
The only difference between the previously suggested RESTRICT=live
value and the new PROPERTIES=live-sources value is that we'll be
using a new variable name and therefore we'll have to add that
variable to the metadata cache in order for it to be accessible
during dependency calculations. This will require the introduction
of a new "PROPERTIES" variable to the ebuild metadata cache that's
distributed via the rsync mirrors and resides locally in the
${PORTDIR}/metadata/cache/ directory.
By using a new PROPERTIES variable instead of the existing RESTRICT
variable, we will have two separate categories of boolean
attributes. This is useful since some boolean attributes, such as
"primaruri" and "live-sources", have an inverted nomenclature when
compared to the other boolean attributes that currently exist within
the RESTRICT set, show here:
binchecks - Disable all QA checks for binaries.
bindist - Distribution of binary packages is restricted.
fetch - Files will not be fetched via SRC_URI.
installsources - Disable FEATURES=installsources.
mirror - Disable mirroring.
primaryuri - Fetch from URLs in SRC_URI before GENTOO_MIRRORS.
strip - Final binaries/libraries will not be stripped.
test - Do not run src_test even if user has FEATURES=test.
userpriv - Disables FEATURES=userpriv.
We can add the new PROPERTIES variable to the metadata cache and it
will be fully backward compatible as long as PROPERTIES only
contains information that can be safely ignored by older versions of
portage. Newer versions of portage that are aware of the new
variable will simply have a superset of the information that's
available to older versions of portage.
The addition of the PROPERTIES variable isn't entirely necessary
since the "live-sources" attribute could be expressed in RESTRICT
just as well. However, numerous people has expressed a desire to
have a new variable to represent a different category of boolean
attributes, so as not to pollute the RESTRICT variable with values
that don't fit well into existing RESTRICT nomenclature conventions.
Shall we move forward with this approach or are there any remaining
issues that people would like to discuss?
Zac
[1]
http://archives.gentoo.org/gentoo-dev/msg_164fd8d5d513121ab772509d06a7b27a.xml
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkiWYOoACgkQ/ejvha5XGaPMuACfQ+9TlGN4gG18HTWvKKncIXzE
Hl8An1FIrlZIq1GV5UnfE5j6gTnVdyBY
=Kc2m
-----END PGP SIGNATURE-----
