On Sat, Oct 02, 2004 at 11:59:49PM +0200, Julio M. Merino Vidal wrote:
> 
> 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.

I think we should fix up pkgsrc to allow subdirectories of arbitrary
depth containing packages within each category.  Then you could do
something like:

    devel
     |-- GConf
     |    |-- GConf-1.x
     |    `-- GConf-2.x
     |-- automake
     |    |-- automake-1.4.x
     |    |-- automake-1.7.x
     |    `-- automake-1.9.x
     |-- cdk
     |-- cvs
     `-- glib
          |-- glib-1.x
          `-- glib-2.x

We would need to hash out the proper way to name package directories,
where I think we want to the somehow encode the "major" version number
as you noted above.  I offer no plan for transitioning to such a
structure, and clearly there are several other problems that would
need to be solved, e.g. locations for buildlink3.mk files, how to
write dependencies in a package Makefile, etc., but it would be nice
to figure out what we would like in an ideal world, and then figure
out how much work it would be to make it come true.

	Cheers,

	-- Johnny Lam <jlam@NetBSD.org>