Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Jun 2012 14:36:00 +0200
From:      Mel Flynn <rflynn@acsalaska.net>
To:        freebsd-ports@freebsd.org
Subject:   Re: ports need a uniq identifier, do you have any suggestion?
Message-ID:  <4FD5E630.3090908@acsalaska.net>
In-Reply-To: <20120611103221.GU60433@ithaqua.etoilebsd.net>
References:  <20120611043001.GO60433@ithaqua.etoilebsd.net> <4FD591DF.3060808@infracaninophile.co.uk> <20120611103221.GU60433@ithaqua.etoilebsd.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 11-6-2012 12:32, Baptiste Daroussin wrote:
> On Mon, Jun 11, 2012 at 07:36:15AM +0100, Matthew Seaman wrote:
>> 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?

UNIQUENAME is a clear name. Abusing it should simply not happen and this
is a case of badly chosen defaults. This is a variable that should not
have a default as it's too expensive to check whether the chosen default
lives up to the standard (being "ports-tree wide unique"), unless you
make this a UUID, which is probably not desirable from an
operator/transparency perspective to have a hierarchy like:
/var/db/ports/PPPP-QQQQ-RRRR-SSSS/options.
Ideally, a port maintainer should assign a uniquename and be responsible
for it. In turn, bsd.port.mk should throw a fit if UNIQUENAME is not set
rather then providing a guess that works "most of the time".

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

If you want to share an options file, you should share the OPTIONSFILE.
Knowing what UNIQUENAME is used for should not be a vehicle to using it
as in the future it can be used for more things or be disconnected from
the functionality you were using it for.


> Maybe they are different packages, but they have the same options, and from
> pkgng we should be able to detect it as the same package just a different
> runtime which is what they are.

Not if they install in version-specific "site-packages". Then they
really are different packages, since the packing list will be different
after expansion of variables. If you count that as "same package", then
definitions are getting real fuzzy and I'm not sure how well that's
going to play out in the long run. The degradation of UNIQUENAME is an
excellent example of how things clearly named end up being not what they
are.

And finally there's the case where extra stuff gets patched or installed
based on the interpreter version. Good example is various perl ports
where functionality from a CPAN module has been integrated into the perl
port itself. So, older modules installed with older versions have (one
or more) extra dependencies. On the plus side, these ports don't change
UNIQUENAME, but that is just an implementation issue. I don't know of
any python ports that change dependencies based on interpreter version,
but I wouldn't be surprised if there are some.

All this only enforces my view that we should standardize versioned
ports and I've started working on it. bsd.databases.mk will be the
victim of my first iteration.
-- 
Mel



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FD5E630.3090908>