Subject: Re: [RFC] code replacement for the PKGBASE, PKGNAME section in bsd.pkg.mk
To: Hubert Feyrer <feyrer@cs.stevens.edu>
From: Roland Illig <rillig@NetBSD.org>
List: tech-pkg
Date: 10/15/2005 08:53:05
Hubert Feyrer wrote:
> 
> +# A B C D  ||  (A = DISTNAME, B = PKGNAME, C = PKGBASE, D = PKGVERSION)
> +#----------=-=-============================================================ 
> 
> 
> That table scares me - there seems to be too much magic, and worst of it 
> all it's undocumented (not that it would make things much better).

My basic assumption behind this table was that all of these variables 
could be used to specify the PKGNAME. So, if you have 
DISTFILES=package-0.4beta7src.tar.gz, you would say:

DISTNAME=    package-0.4beta7src
PKGVERSION=  0.3.998.7

That way you don't need the ugly PKGNAME=${DISTNAME:C/.../} in the 
package Makefile. Yes, some of you can already read that fluently, but 
there's always some trickery involved in regular expression 
search&replace. This change would make reading easier for humans 
(especially newbies), and _much_ easier for computers (we have some 
scripts that try to parse Makefiles to get the PKGNAME quickly). So I 
want this first paragraph to be expressed as simple as possible.

But when I looked at the way DISTNAME, PKGNAME, PKGBASE and PKGVERSION 
are derived currently, I noticed that almost no packages set PKGBASE and 
PKGVERSION directly. And if they do, they are either redundant (setting 
them to the default value) or plainly wrong (using PKGVERSION instead of 
PKGREVISION).

So what's more likely is that the code for determining PKGBASE and 
PKGVERSION should not use the "?=" assigment operator, but something 
like the following:

.if !defined(PKGBASE)
PKGBASE=     ${PKGNAME:C...}
.else
PKG_FAIL_REASON+= "[bsd.pkg.mk] error: PKGBASE is a read-only variable"
.endif
# same for PKGVERSION

I wouldn't have had the idea of such an overly complex table if the code 
had looked like the one above. :)

> Plus I'm with Cube that first thing you go from a pkg is the DISTNAME.

When creating a package, I keep the PKGNAME (as defined by the upstream 
authors) or the DISTNAME in my mind and start with choosing a category. 
Then I choose a PKGNAME (if the DISTNAME does not match the requirements 
for a PKGNAME) and mkdir ${PKGNAME}. Then come the MASTER_SITES and only 
then the DISTNAME. So my order differs a lot. :)

I like to read the first paragraph as follows: "This is the ${PKGNAME} 
package, in categories ${CATEGORIES}. To download it, go to one of 
${MASTER_SITES} and download ${DISTFILES}." That's exactly my preferred 
order of variables.

> I don't understand what the motivation behind this change is, other than 
> some aesthetic one.

The scheme for choosing PKGNAME and PKGVERSION has been equally complex 
before, although it was unintended. I just made a table of all possible 
cases that could appear and thought about what would be the best way 
(according to _my_ ideas about the name selection) to define the other 
variables based on the given ones.

Roland