Re: [HEADS UP] PKGTOOLS_REQD bump and related changes

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Mon, Jun 15, 2009 at 10:30:42PM +0200, Joerg Sonnenberger wrote:
> On Mon, Jun 15, 2009 at 09:19:43PM +0100, Alistair Crooks wrote:
> > On Mon, Jun 15, 2009 at 09:46:43PM +0200, Joerg Sonnenberger wrote:
> > > Hello all,
> > > before the freeze I have commmitted the following large scale changes.
> > > This can result in some fallout, so be warned:
> > > 
> > > (1) License infrastructure
> > > 
> > > The license check is now using pkg_admin and allows boolean expressions.
> > > E.g. LICENSE= artistic OR gnu-gpl-v2.  If you get complains about
> > > PKGSRC_ACCEPTABLE_LICENSES, check your mk.conf.  Valid license names are
> > > lower case only.
> > 
> > Yeah, it might be a good idea to accept upper and lower case, and fold
> > the case to lower on input (so that the hashing still works).
> 
> Given that it is a one-time change I am not sure if case-folding is the
> best approach. It also checks for other characters, upper case letters
> are just the most likeliest candidate. With 20090610 it is better at
> pointing to the error as well.

Right, so let's consider that this isn't a one-time change, and that
people are used to thinking of licenses in terms of acronyms - MIT,
GPL, BSD etc.  That was really the basis for my suggestion that you
fold the case of the licence on input, and just hash based on the
lower case value.  In pkgsrc, we think of users over implementors - we
do what's best for the users of pkgsrc, not what's the least effort
course for the developers.  Incompatible changes are to be avoided at
all costs.  Sorry that hasn't been made clearer.
 
> > > (2) @dirrm
> > > 
> > > pkg_delete is performing automatic pruning of directories now. Empty
> > > directories in packages can be requested by @pkgdir in the PLIST and
> > > will be considered. As some packages had quite a bit of magic related
> > > to @dirrm entries, there might be some fallout. I am running a bulk
> > > build now to identify those issues.
> > 
> > Is the @dirrm directive not recognised any more, or is there an error or
> > warning message attached?
> 
> It is silently ignored. The edge cases where it doesn't work are small
> enough that I don't think a warning is justified.

Ah, right, silent ignorance - not really a good policy at any time,
and especially not when it comes to adding an old binary package. 
Forcing everyone to re-compile binary packages is a bit of a copout,
isn't it?

Regards,
Alistair