Re: Bug#1187: Various `vi' versions trample on each other.
iwj10@cus.cam.ac.uk (Ian Jackson) said:
> Bill Mitchell writes ("Re: Bug#1187: Various `vi' versions trample on each other."):
> > [...]
> > As I understand it, you're asking that the processing be changed so
> > that programs would install themselves under package-specific names,
> > and would optionally link package-specific binary names to more
> > generic names ("vi", "ex", ...) if those names are not in use.
> >
> > The first vi clone installed, then, would use whatever generic names
> > it wanted. vi clones installing later would only use names which they
> > wanted and which were still free (perhaps "ex", but not "vi").
> >
> > You're also asking that package-specific manpage names be used, and
> > only linked to generic names if the binary link is done, and that the
> > manpage link be put in place of whatever file or link might pre-exist
> > it.
>
> I'm suggesting that we
each involved package maintainer, individually
> do this if we
all of us, collectively
> want to be able to support having
> several different versions of a program on the system.
You're suggesting that each individual package maintainer do this, and
they all do it the same, and that nobody forget to do it, and that nobody
make any mistakes doing it. That sort of thing is better done centrally,
because if it's done separately, you can count on everybody doing it
slightly differently, and on somebody forgetting to do it altogether.
> > [ObMention of package-granularity vs. file-granularity handling of
> > dependencies and conflicts]
>
> OK, I'll bite. What do you think should happen when two packages
> contain a file with the same name ?
We've discussed that in detail, previously. It's like explaining
dpkg internal mechanisms in that it tends to get long and involved.
I can start my side of the discussion up again, if that's what's
wanted. We can do it privately, on debian-devel, on debain-private,
on some other list, or wherever. Having gone through long discussions
on this previously which ended up as timewasters, however, I don't
want to get into the details again if I'm proposing change where
a decision has already been taken that change is not an option.
We continue to have problems which fall into this general area.
I maintain that it's because we made a bad requirements decision early-on,
and we're locked into a design which grew out of that bad requirements
decision, and that we'll continue to have trouble fitting that design
to the actual requirements which have emerged.
It's possible to migrate gracefully from one scheme to another, but
it becomes more difficult with each increase in the size and complexity
of the distribution.
> Currently (dpkg 0.93.64) that from the package installed earlier will
> be overwritten by that from the package installed later. The file
> will be considered part of the second package, so that it will be
> removed iff that package is removed.
and it'll also be removed if the first package is removed.
Script started on Wed Aug 2 07:14:13 1995
# dpkg --build test1
dpkg-deb: building package `test1' in `test1.deb'.
# dpkg --build test2
dpkg-deb: building package `test2' in `test2.deb'.
# dpkg --contents test1.deb
drwxr-xr-x root/root 0 Aug 2 07:09 1995 ./
drwxr-xr-x root/root 0 Aug 2 07:09 1995 root/
-rw-r--r-- root/root 15 Aug 2 07:12 1995 root/file1
-rw-r--r-- root/root 46 Aug 2 07:09 1995 root/file
# dpkg --contents test2.deb
drwxr-xr-x root/root 0 Aug 2 07:10 1995 ./
drwxr-xr-x root/root 0 Aug 2 07:10 1995 root/
-rw-r--r-- root/root 48 Aug 2 07:10 1995 root/file
-rw-r--r-- root/root 15 Aug 2 07:08 1995 root/file2
# pwd
** test1 and test2 both contain file, and some other stuff.
** this is similar to two vi clones containing /usr/bin/vi
/root
# rm file*
rm: file*: No such file or directory
# dpkg --install test1.deb
Selecting previously deselected package test1.
(Reading database ... 8003 files and directories currently installed.)
Unpacking test1 (from test1.deb) ...
Setting up test1 ...
# ls file*
file file1
# cat file
this is the collision file from package test1
# cat file1
this is file 1
# dpkg --install test2.deb
(Reading database ... 8004 files and directories currently installed.)
Preparing to replace test2 (using test2.deb) ...
Unpacking replacement test2 ...
Setting up test2 ...
# ls file*
file file1 file2
# cat file
this is the collision file from package test2.
# cat file1
this is file 1
# cat file2
this is file 2
** ok -- test1 installed file
** then test2 overwrote file
# dpkg --remove test1
(Reading database ... 8004 files and directories currently installed.)
Removing test1 ...
# ls file*
file2
** test1 was removed. It removed the copy of file installed by test2
# dpkg --version
Debian GNU/Linux `dpkg' package management program version 0.93.64.
Copyright 1994,1995 Ian Jackson, Bruce Perens. This is free software;
see the GNU General Public Licence version 2 or later for copying
conditions. There is NO warranty. See dpkg --licence for details.
#
Script done on Wed Aug 2 07:16:27 1995
>
> This allows files to be transferred between packages without ever
> having to remove any of the packages involved.
but, if some of the packages are removed, they may remove files "owned"
by other packages which were installed later.
> A few alternatives I can see are:
>
> (a) Treat files of the same name in two different packages as an
> installation error (a bit like a conflict - though of course it
> couldn't be detected in advance, so dselect wouldn't know about it).
> This seems to me to be unhelpful.
If by "in advance" you mean pre-install, it could be detected easily.
It can be detected pre-install with current packages, but it takes a
lot of install-time overhead to do it. It could be detected easily if
packages contained a header file constructed at package-build time
whach listed their contents. Having this info in a header file in the
package goes thru that overhead at package build time, and requires much
less overhead at package install time. It's also handy for other reasons
if this header file gives the size and md5sum of each file which the
package will install.
> (b) As I do at the moment, but only remove the file when the last
> package which contained a version of it is removed. This will prevent
> one from ever forgetting about base packages. At the moment base
> packages can be forgotten about by having other packages take over all
> their files. If we do take this approach it will be much harder to
> rename base packages. (Note that all of this applies to non-base but
> important widely-Depended-on packages, too.)
I'm getting lost here, trying to track just exactly what we're
trying to accomplish with this. I just tried to come up with a
usage example for this, and couldn't.
I think it'd be more effective to approach this by first defining
what we're trying to accomplish, and then deciding how best to do it
than by looking at what's convenient to implement by building on
current dpkg internals and trying to specify requirements which fit
that.
(I just re-read that last paragraph. It sounds like a troll, but
it's not intended that way. I do honestly think it'd be best to
divorce requirements definition from implementation concerns,
and that we're not doing that.)
> (c) Allow package maintainers to assign a priority level to each file
> in each package (with a sensible default), and do as I do now if the
> new package's priority for the file is higher or the same as that
> installed, but ignore the new version if it is lower. This seems to
> me to be overcomplicated and not very elegant.
It seems to me that a scheme which requires close coordination between
separate maintainers of separate packages is unlikely to work well.
> dpkg already supports something that's better than `file-granularity
> handling of dependencies', whatever that means. Virtual package names
> do not need to be names in the filesystem, and because they must be
> declared in the package control files (and thus in the Packages file)
> they can be used by dselect.
You say that you don't know what this thing which dpkg is better-than is,
but you do know that dpkg is better-than whatever it is. Can't argue
with logic like that.
I agree that virtual package names are a good thing -- or will be if
we ever arrive at a workable scheme for actually using them effectively.
However, what I've been calling "file-level granularity dependency and
conflict handling". isn't the same thing as virtual package names.
I admit that the handle I've been using is clumsy, and doesn't convey
all the details. THe details have been discussed, and I'm open to
revisiting that. Whenever we talk about taking special measures to
deal with files within a package in some special way (and we do talk
about that quite a bit), we're hacking around inadequacies which don't
provide us the tools needed to handle things in a well-defined, supported,
uniform, reliable, consistent manner.
Reply to: