On 11/06/2012 05:30, Baptiste Daroussin wrote: > In the ports tree we lack a unique identifier, while we could live without it > until now, it is more than needed for 2 upcoming features: pkgng and stage > directory support. > > unique means something that will always be the same what ever the options are > and what ever the runtime they use are. But also means unique in term of in > the > whole ports no other package will share its identifier. > > currently the only equivalent of this in the ports tree is the origin of a > package, which will no more be unique with the upcoming sub package support > (coming along with stage directory) aka 1 origin to produce n package. > > UNIQUENAME and LATEST_LINK fails in that area because they both can change > according to the runtime: py27- for example which will become py30- if you > change the default python. > LATEST_LINK by default also append the PKGNAMEPREFIX which some ports can be > really creative with. > > should we introduce something new, should we fix one of the above? do you have > any suggestion?
I was looking at this. You'ld think from the name that UNIQUENAME is
the appropriate variable here. Yet by my calculations there are 1439
ports using non-unique UNIQUENAME variables. Fixing that seems like
common sense to me: why call it unique if it isn't?
UNIQUENAME importance being because the default location for a port's
OPTIONSFILE is derived from it, and non-uniqueness can lead to ports
fighting over control of that file? Which is bad when unintentional,
but can be useful for some related ports to share the same options settings.
Does pkgng really need LATEST_LINK at all? As far as I recall, that
only exists so that the user can say:
# pkg_add -r firefox
without having to look up the version number of the firefox port. But
pkg(1) pretty much already lets you do that, maybe with the aid of '-x'
or '-X' options. Come the pkgng revolution, LATEST_LINK should be one
of the first against the wall.
I don't see the problem with port prefixes changing UNIQUENAME. Isn't
py27-foo conceptually a different port to py30-foo ? Yes, they are
built from the same port ORIGIN, but you already intend dropping the
one-to-one correspondence between port ORIGINS and packages with the
introduction of sub-ports.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
