[gentoo-dev] [RFC] Should we introduce PROPERTIES into the ebuild metadata cache on the rsync mirrors?

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everyone,

Please consider 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.
This variable is intended to have identical syntax to the existing
RESTRICT variable, including support for the USE conditional syntax
that is also supported by the LICENSE, PROVIDE, SRC_URI, and *DEPEND
variables.

The idea to introduce the PROPERTIES variable arose from discussion
about the introduction of a new RESTRICT value [1]. By using a new
PROPERTIES variable instead of the existing RESTRICT variable, we
will have two separate categories of boolean attributes. This will
be 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 any PROPERTIES value can alternatively be expressed as a
RESTRICT value. However, numerous people have 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.

We haven't made any firm decisions yet on specific PROPERTIES values
and their meanings. However, it would be nice to have the cache
support in place so that we are prepared to start defining
PROPERTIES in ebuilds as soon as we've decided on the names and
meanings of specific values such as "live" [2], "virtual" [3], and
"interactive" [4].

Introducing the PROPERTIES variable into the cache will require a
very small patch to portage. As soon as this patch is applied to
portage on the master rsync mirror, it will be possible to define
the PROPERTIES variable in any ebuild and have that value
automatically distributed via the metadata cache on the rsync
mirrors. The current cache format has space to store the values of
22 variables, delimited by newlines, of which 7 are currently
unused. The attached patch will cause the PROPERTIES value to be
stored on line number 16, following the EAPI value.

Should we go ahead an apply this patch to the master rsync mirror,
or would anybody like to discuss any alternatives? In the future we
may want to discuss a change in cache format. However, in this
thread I think we should limit discussion simply to whether or not
adding this one variable to the cache is a good idea at this time.

Thanks,
Zac

[1]
http://archives.gentoo.org/gentoo-dev/msg_d8adb5d0dab3e8546c416781c452d81d.xml
[2]
http://archives.gentoo.org/gentoo-dev/msg_187585c5d49b69034183719ff473710d.xml
[3] http://article.gmane.org/gmane.linux.gentoo.devel/57610
[4]
http://archives.gentoo.org/gentoo-dev/msg_e145fc04e907de72e30d88285afb134c.xml
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiiJGIACgkQ/ejvha5XGaMIfQCguxt0Z0k1V3SEtW+PrhQPsdIK
MPIAn37AWGFONJsbdD6oRJryzQ8EHkxt
=d5Jf
-----END PGP SIGNATURE-----