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

Re: I'm confused... where do X11 bins go?



On Tue, Jun 01, 1999 at 12:15:22PM -0500, Manoj Srivastava wrote:
> >>"Branden" == Branden Robinson <branden@ecn.purdue.edu> writes:
> 
>  Branden> I see so reason /usr/X11R6 has to continue to exist at all.
> 
>         One reason that I have encuntered in the past was the need to
>  maintain a working, older version of X (say, R6) while toying with a
>  newer release (say, R7). Having separate directories in /usr allowed
>  my to have both versions installed on the machine (this was a
>  departmental server). 

There are two problems I see with this argument:

* It applies to any major component of the system. Indeed, the same reason
could be given for Gnome or KDE, for example. Still, we don't allow this
scheme for new packages. KDE had to be repackaged (before we throw it out).

* It doesn't take the packaging system into account. It is questionable if
we (as a distribution) will make it possible to install two versions of X at
the same time. For example, some clients install into X11R6, some into
/usr/bin. Some installing a latest version for testing purpose seems to be a
local administration issue.

No system administrator should use /usr, but /usr/local.

Any system administrator can install the latest X into /usr/local or
/usr/local/X11R7 or /opt/X11R7 and set the path for testing. If you put it
in the front of your path, it will be used.

I think for us as a distribution this is a weak argument. It is a
strong argument for a sysadmin to install a test release of X in a seperate
directory.

Of course, seperate directiories make it easier to install concurrent
versions. Debian does support concurrent versions very poorly anyway, and
only for some package. This is a general problem. It would be an interesting
task to solve this problem more general in dpkg itself, by allowing a
concept similar to stow applied to packages to install multiple versions.

I would much prefer to have a good, general solution to this than to have a poor
solution grandfathered to a single package.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann              GNU    http://www.gnu.org     master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09


Reply to: