Re: /usr/ports/LICENCE

[Tim Vanderhoek <vanderh@ecf.utoronto.ca>]

On Tue, Aug 24, 1999 at 03:16:55PM +0200, Marc Espie wrote:
> > > 
> > > name somehow... even though there are no clear rules as far as version
> > > numbering goes.
> > 
> > FreeBSD has had clear rules from at least since the beginning of
> 
> Those rules are somewhat implicit, and not that well known...

There is an approximately 3 page long section in the porting
guidelines.  It's been there for quite a while, but it is buried near
the end of the guidelines.


> So that, eventually, port names may look like
> 
> ident-flavor-version-port_version
> 
> This can become a little hard to parse...
> What would you suggest ?

Adding port_version is an interesting idea.  The bumping of
port_version would need to be explicitly for non-cosmetic changes (ie.
it couldn't be automated).

I'm not sure where OpenBSD uses port names.  Tagging the end of port
names with port_version could be confusing to users trying to
compare the ported software version to the latest software version.  I
think this would be a showstopper for FreeBSD --- OpenBSD having fewer
port users (and perhaps more intelligent ones) may be able to get away
with appropriate documentation.

Maybe port_version is something that should be silently stored in
${PKG_DBDIR} instead.  Whenever the user updates their /usr/ports/
directory, a script could check for ports to update (there already
exists such a script that operates for ported-software-version updates).

You should add a language code.  Approximately 15% of FreeBSD's ports
are language-specific.  This will undoubtedly affect OpenBSD
eventually.  We put the language code before ident.  It could arguably
be part of flavour, but this may get a little complicated (see end of
message).  We have some port named like ``afterstep-i18n-1.0'',
which is correct by our rules.

You may want to add a place for tags such as "-devel" or "-latest",
sometimes used when two ports of the same software are kept.

I would be a somewhat wary of adding 5 new supported variables simply
for the purpose of setting a port name.  One of the things we've tried
to do is keep a fairly high level of information density new the top
of Makefiles.  Surprisingly we really haven't had much trouble at all
enforcing proper PKGNAMES in FreeBSD.  Given a PKGNAME that follows
the proper guidelines, it can be parsed fairly easily (with possible
exception of flavour).

I don't have any great suggestions on how to standardize the flavour
part of a port name.

Things like "enscript-letter" and "enscript-a4" are pretty easy.
They mean "enscript, configured for `letter'" (whatever `letter'
is).

It becomes more complicated when you try something like
"apache+php-1.3.6+3.0.12" which means Apache with PHP compiled-in.
In some cases we've used (probably foolishly) an underscore, eg.
"apache_fp-1.3.6" (no FrontPage version number).

We also have some ports that use a `+' to combine multiple
flavour-options.  This seems to increase readability and I think we
should try to use it more often.

In some cases FreeBSD has a dash as part of what you referred to as
the ident.  This is bad; we should use underscores.  The last
port to try this "linux-devel" was correctly renamed to "linux_devel"
partly for this reason.

It gets a little ugly when a port wants to refer to another port
in flavour.  "bitmap_font-mule-7.18" is the first example I found
when looking for examples of this.  That's the bitmap_font port
customized for the mule port.  For more fun, try ports like
"yatex-xemacs-mule-1.66" which is the yatex port set to work with
the xemacs-mule port (and hopefully any xemacs-mule-derived port,
since there are tens of emacs ports).

Differentiating between ident and flavour can be tricky sometimes.
For example, "netscape-communicator-4.08", "netscape-navigator-4.08",
and "netscape-gold-3.04".  For more fun, we also have a port
"netscape-communicator-4.07.us" (and corresponding -gold and -navigator
versions).

Be careful of implementing anything that doesn't allow some
flexibility.  I've only listed examples of problems that occur
multiples, not examples with only one occurrence...


-- 
This is my .signature which gets appended to the end of my messages.