[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Naming (Re: Unified packages. )



On Sun, 20 Aug 2000, Adrian Filipi-Martin wrote:
> > ie, mozilla-M17.i386.Openbsd27.upc
...
> 	As for compiled binary package naming, I'm quite content knowing
> that yoyodyne-1.33.pkg works on the system I built it on.  For massive
> archives, I'd be happier with the architecture and platform encoded in the
> path prefixes.  It allows you to set your "context" with "cd" and know you
> are only seeing relavent software.

Seconded. That way we can reuse lots of code, and at least *i* was always
glad that I can use pkg_info on i386-pkgs with pkg_info running on sparc,
withouth pseudo-smart tools telling me that i'm on the wrong arch.


> 	For the time being, I'd like to see us stay focused on systems that
> use bmake out of the box.  I think we all know which systems these are.
> Otherwise we might as well port Debian's package/make system.

We should take into consideration that bmake != /usr/bin/make of any BSD
system. make(1) seems to different on these systems, unfortunately. (Or so
I've heared, e.g. when it comes to variable modifiers: ${FOO:x...}


> 	I'll be quite on the name issue now.  What does everyone find to be
> the compelling features under their favorite version of the "ports"
> hierarchy?  I'll gather these together.  I'll also try to read the pkg_*
> CVS log entries to see what each the platforms and summarize.

Good point, and to repeat someone which I talked this over with: we should
aim for the most advanced pkg technologies, not the least common
denominator.

For NetBSD, I consider these as major:
 * Full support for wildcards in both "src" as well as binary pkgs
 * Some support for bulk building all packages, to ensure pkgs
   work (see ftp://smaug.fh-regensburg.de/pub/NetBSD/pkgstat/20000819.1320/broken.html
   for an example)
 * Support for Solaris (it *is* being used!)

Other features from NetBSD that might be interresting:
 * A package database to findout which pkg a file belongs to
 * Installed and binary pkgs contain the size of the pkg
   in bytes. Also, the size including all required pkgs is available.
 * Pkgs can be deleted recursively, e.g. to nuke jpeg and everything
   that needs it (very handy)
 * Detection of out-of-date pkg_* tools if bsd.pkg.mk uses a feature
   that the installed pkg_* tools don't provide.

See the last part of
http://www.netbsd.org/Documentation/software/pkg-wildcards.html for more
information.


 - Hubert

-- 
NetBSD - because Unix isn't just #include <linux.h>, i386, ILP32, ELF, ...!


To unsubscribe: send mail to <majordomo@unixathome.org>
with "unsubscribe bsdports" in the body of the message