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