Subject: Package naming and major versions [was Re: CVS commit:
To: Jeremy C. Reed <email@example.com>
From: Julio M. Merino Vidal <firstname.lastname@example.org>
Date: 10/02/2004 23:59:49
On Sat, 2 Oct 2004 07:57:35 -0700 (PDT)
"Jeremy C. Reed" <email@example.com> wrote:
> On Sat, 2 Oct 2004, Rene Hexel wrote:
> > I don't think this is a good idea. This way we will have to keep
> > renaming packages (as this is a moving target), with tons of
> > unnecessary rebuilds. If packages are renamed at all, I would suggest
> > renaming gal to gal1 and gal2 to gal22. This way, there is no "gal"
> > package and there is no need to constantly rename packages in the
> > future.
> That sounds like a good idea. (Although my preference is to have
> package names and directory like gal2.2, such as gal2.2-2.2.1).
Indeed. I really think that we should normalize the current situation
in pkgsrc. Every package follows its own naming rules, and there is a
big naming mess. For example, we have GConf (version 1.x), GConf2 (version
2.x), gnome-applets (1.x version), gnome2-applets (2.x version), gnome-panel
(2.x version), gnome1-panel (1.x version), and a long etc. And not to say
the situation with gal, gal2 and gal22.
What you said sounds good: just make all packages have their "major" version
number encoded in the package name, iff there are several versions of it
available (to be installed at once) now or in a near future.
And I think I prefer Jeremy's notation too; gal20, gal22 may be confusing,
whereas gal2.0 and gal2.2 can't lead to confusion (maybe this package is not
the best one to see the problem...). FWIW, Debian uses this scheme too.
Julio M. Merino Vidal <firstname.lastname@example.org>
The NetBSD Project - http://www.NetBSD.org/