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
architecture.
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 .
.
./bin
./bin/gdb@sgi4i5
./bin/gdb@dsult4
./bin/gdb@hp700ux9
./bin/gdb@sun4os5
./bin/gdb@alphaosf3
./bin/gdb@sgi3i4
./bin/gdb@sun4os4
./emacs
./emacs/info
./emacs/info/gdb.dir.compilers
./emacs/info/stabs.info
./emacs/info/gdb.info-5
./emacs/info/gdb.info
./emacs/info/gdbint.info
./emacs/info/gdb.info-1
./emacs/info/gdb.info-8
./emacs/info/stabs.info-3
./emacs/info/gdb.info-4
./emacs/info/gdbint.info-2
./emacs/info/gdb.info-7
./emacs/info/stabs.info-2
./emacs/info/gdb.info-3
./emacs/info/gdbint.info-1
./emacs/info/stabs.info-1
./emacs/info/gdb.info-6
./emacs/info/gdb.info-2
./emacs/info/stabs.dir.compilers
./emacs/info/gdbint.dir.compilers
./emacs/info/gdb.info-9
./man
./man/man1
./man/man1/gdb.1
storm:/store/store/ernie/gdb/ver-4.15.1$
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.
Regards,
astor
Reply to: