Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 01 Nov 2011 15:20:13 +0100
From:      Alfred Bartsch <bartsch@dssgmbh.de>
To:        Matthew Seaman <m.seaman@infracaninophile.co.uk>
Cc:        ports@freebsd.org, Chris Rees <utisoft@gmail.com>
Subject:   Re: An intruiging INDEX problem -- slave ports + make.conf KNOBS
Message-ID:  <4EB0001D.6020600@dssgmbh.de>
In-Reply-To: <4EAEEE8A.8020601@infracaninophile.co.uk>
References:  <CADLo839VEniObE%2BPvGy-BPYwki=7G8QmZsRHt_gTcD4ESSZPyQ@mail.gmail.com> <4EAEEE8A.8020601@infracaninophile.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 31.10.2011 19:52, schrieb Matthew Seaman:
> On 31/10/2011 17:39, Chris Rees wrote:
>> Apparently if you define something in make.conf that slave ports
>> also define, then a generated INDEX becomes useless...
>> 
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/162088
>> 
>> Basically, jpeg2ps-a4 -slave port of-> jpeg2ps-letter which
>> defines A4=yes, and turns jpeg2ps into jpeg2ps-a4, thus
>> duplicating INDEX records. Unfortunately, the master port is
>> indexed first, so jpeg2ps-a4 is left with an incorrect origin...
>> 
>> Does anyone have any clever ideas around this?
> 
> One or two.  The generic code for building the INDEX treats this as
> an error, but I don't see why that should be so.  Either you decide
> that the package name column (the 1st column) should be the unique
> entry in the INDEX and so you drop any duplicates, or you decide
> that the second column -- directory path of the port -- should be
> the unique field.

At that point it might be difficult to decide, whether a certain
duplicate line is to be kept or can be dropped. IMHO, *both* columns
should be unique and complete,so that each port directory is
represented by one separate line in INDEX.

> 
> The second option there makes more sense to me, as it better
> reflects reality: with certain make variable settings there will be
> two or more directories within the ports tree where building the
> port will result in installing exactly the same port.  However the
> assumption made by most of the software that interacts with the
> INDEX is that the first column is the unique key.

IMHO, due to uniqueness, installing a package of the same name from
different port directories should never happen. Therefore package
naming always has to differ, whether the installation is invoked from
the master or slave portsdir.

In the case of the "jpeg2ps" and similar ports this could be achieved
by creating a *real* master portdir "graphics/jpeg2ps" and some slave
portdirs like "graphics/jpeg2ps-letter", "graphics/jpeg2ps-a4" etc.
Using PKGNAMESUFFIX (related to PAPERSIZE) should then be restricted
to the slave ports. The package origin would then always be fully
documented in INDEX.

IMHO serving all possible slave precompiled packages at
ftp.freebsd.org is only of limited value. As long as I do not locally
rebuild some packages with a4-setting, only the -letter packages are
resolved as dependencies via "pkg_add -r". So why not drop all of
those slave ports and use a general option (PAGESIZE=) in
/etc/make.conf or locally in master port's Makefile instead?  Even
today, users with an environment other than default (Northern America,
en-US) have to rebuild some ports locally to fully fit their needs
(default paper size for printing is only one major example).

> 
> Any way, my ports-mgmt/p5-FreeBSD-Portindex code will generate an
> INDEX file for you despite this sort of collision.  By default it
> operates to make the first column the unique key, but that can be
> very easily changed if wanted.
> 
> Cheers,
> 
> Matthew
> 

- -- 
Alfred Bartsch
Data-Service GmbH
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6wAB0ACgkQ5QGe2JdVf3iAGwCgskSzF2eCPGRJrUbot19Zn8qU
g4QAni25AkQl4pNYe5Sr3f3XWQD0WIJI
=t1VG
-----END PGP SIGNATURE-----



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