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

Bug#101870: Update multiple version handling policies



Package: debian-policy
Version: 3.5.5.0
Severity: normal

I would like to see an update on the policies for dealing with multiple
versions of the same program.  For instance, GCC and friends are
packaged in the 2.95 and 3.0 versions.  It would be nice to have a
standard in the policy for dealing with having both versions installed
and picking a default.  I have looked through the current policy and it
refers to past policy when talking about dpkg-divert and the
alternatives system.  I believe that this situation would be best
handled by the alternatives system, as this system is less hacky than
the dpkg-divert system.  In the GCC example, this is how the symlinks in
the GCC family are currently.

/usr/bin/gcc -> gcc-2.95
/etc/alternatives/cc -> /usr/bin/gcc

Similar symlinks exist in all GCC related packages (g++*, g77*, etc.).

Now this makes sense until you realize that gcc-2.95 and gcc-3.0 both
provide "c-compiler".  Furthermore, they are two versions of the same
program.  They can be looked at as two different programs offering
identical functionality (much like the difference java compilers that
are packaged).  In order to make it easier to pick a default compiler
(not neccessarily GCC even) I would like to see the following happen in
the symlinks of the gcc packages (this type of setup is seen in the java
compilers).

/usr/bin/gcc -> /etc/alternatives/gcc
/etc/alternatives/cc -> gcc
/etc/alternatives/gcc -> /usr/bin/gcc-2.95

I have a special /etc/alternatives/gcc because we are dealing with
multiple versions of gcc and both a command for gcc and cc exist.

This is an elongated example designed to illustrate my proposed policy
clarification.  The choice of a default c compiler is a per system
configuration option that belongs under /etc and /etc/alternatives is
a very elegant way to do this type of thing.  Other types of programs
like pgp and gpg could be offered this same way (assuming somehow they
were made to be commandline compatible--maybe through wrappers?).

Notice that if I want to change to gcc 3.0 for my default I redo the
symlink in /etc/alternatives/gcc where all of the other alternatives on
the system is stored.  Right now I had to track down the fact the
/usr/bin/gcc is linked to the default compiler.  This is insane with the
alternative system that provides a way to move this configuration under
/etc, where all per system configuration belongs according to FHS.  As a
side note, if I wanted to install Joe Blow's c compiler I could relink
/etc/alternatives/cc to it.

Notice also that this is a per system configuration on the basis that my
computer could have a commercial C compiler on it while yours has the
GCC suite.

This policy is more generally about two programs that provide the same
functionality (whether they are different programs or just different
versions is irrelevant if both provide the same functionality).  If this
type of policy were official, Debian would be a more customizable system
while still being every bit as powerful.

This would be more customizable because it would allow easier
installation of alternative programs that do the same as the other
alternatives.

Also, I want to make it known that I do know that there are differences
between the way GCC 2.95 and GCC 3.0 compile code that can cause
warnings or errors to crop up on one compiler but not the other.  This
is irrelevant in this discussion because (1) code needs to be updated to
GCC 3.0 anyway and (2) they are both gcc c compilers.

--Warren

-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux braindead 2.4.5wacom #1 Tue Jun 12 22:09:15 EDT 2001 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages debian-policy depends on:
ii  fileutils                     4.1-2      GNU file management utilities.    




Reply to: