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

Re: FTP Installation & Package Naming Conventions

On Fri, 1 Dec 1995, behan (b.) webster wrote:

> Putting "()" in a file name is a real pain because it has special meaning
> to most shells (eg: it starts a sub-shell in csh).
> You'd have to use "XF86-Accel\(3.1.2\).deb" to access the file.  All in
> all a real pain.
> Just to add my 2 cents to the naming convention fray, IMHO the package names
> should probably have the following information in them:
> \1 package name
> \2 s/w version
> \3 package version
> \4 architecture (i386, alpha, sparc, etc.)
> \5 architecture package version
> ^(.*)-([^-]+)-([0-9]+)(\.(i386|alpha|sparc)-([0-9]+))?.deb$
> Elf packges needn't be labelled as such because debian 1.0 is going to be
> all ELF anyways.  "aout" packages can be prefaced by "aout-" (just like the
> current aout gcc and binutils).
> aout-gcc-2.6.3-11.i386-3.deb
> gcc-2.7.0-2.i386-1.deb
> doc-0.93-5.deb

The reason I'd go for the '@' separation character between the package
name and the architecture-architectureversion is that it highlightes a
clear distinction between the architecture-specific parts of the package,
and the package name/revision. Debian source shouldn't be architecture
specific if we can avoid it, but some packages will be architecture
specific whether we like it or not. Having a special character that will
make these special packages stand out is an advantage. The '@' sais: This
file contains files/information that is specific to a specific

emacs19-19.30-2.tar.gz - should be standard for almost any package, but
lilo-16-1@i386.tar.gz  - should be the exception.. 

I prefer to compile all packages myself. The reason is that I run alpha 
libraries and such that I want to use. Say I want to get all packages 
that I can compile, I'd get .*@i386.* and [^@]* (this requires that no 
other parts of the packagename is allowed to include the '@' character - 
not very restrictive IMHO)

If the architecture is a part of the packagename I'd have problems doing 
this without parsing the name into the different sections.

Let me add that this naming scheme is taken from the package distribution 
system we use at our university. In this system, any _file_ that is 
architecture specific will have an architecture-os tag. This makes it 
possible for us to have a version-tree for all architectures in one 
place. Let me give an example from the version-tree of gdb ( a 
version-tree contains the finished program, a source tree contains the 
original source code):

storm:/store/store/ernie/gdb/ver-4.15.1$ find .

When debian comes for several architectures it might be an idea to try to 
build some kind of version-tree like this to save disk-space on 
distribution sites. It would be easy to construct a tool to make a '.deb' 
file for a specific architecture from this tree. Why not make a 
web-interface to do the job :-).. 

Well.. I'm being carried away somewhat here. Time to get back to my studies.


Reply to: