Re: Bug#1187: Various `vi' versions trample on each other.
Bill Mitchell writes ("Re: Bug#1187: Various `vi' versions trample on each other."):
> > 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.
OK. How about I make a program, part of dpkg, to do this ? Just like
update-rc.d and install-info and what have you ?
> > > [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.
It's not clear to me that
(a) you understand in detail the way dpkg operates at the moment
or
(b) you have a clear and detailed idea of the way you'd like things
to work instead.
These things may be the case, but as I say I'm not yet convinced.
> 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.
I disagree.
> > 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.
This is a bug. Thank you for spotting it.
> > 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.
No, by `in advance' I meant `so that dselect can know about it' (hence
my wording "couldn't be detected in advance, so dselect wouldn't know
about it").
dselect doesn't have access to the .deb files until after package
selection has taken place. All the information necessary for package
selection has to be distributed separately. (This is clearly
necessary for floppy-based installation to avoid having to fee all the
floppies through twice.)
This information can't contain a list of all the files in each package
in the distriubution, as this would clearly be too large even if
compressed well.
> > (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.
Suppose the FSF rename their `diff' package to `diffutils' and we
decide (for whatever reason) that we want to do so too.
We can't ever remove diff, because it is a base package - it can't
even be deslected, so a conflict is not really an option.
Instead, we simply install the new package over the old, and dpkg
notices that the old package has been overwritten completely and
forgets about it.
> 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
This is exactly what I did when I designed the way dpkg currently
deals (or is supposed to deal, modulo bugs) with different packages
containing the same file.
> than by looking at what's convenient to implement by building on
> current dpkg internals and trying to specify requirements which fit
> that.
That's not how the new C dpkg was written, I assure you.
> (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.)
I for one have been working at several levels of abstraction, from `we
want modular packages' right down to `such-and-such a struct contains
three pointers, ...', throughout the development of dpkg.
> > (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.
Indeed.
> > 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.
English is a marvellous language. There is a lot of redundancy in it.
This can be used, amongst other things, to say in a few words what
would take many to express if spelt out in detail, because the astute
reader will notice what is going on.
What I meant when I wrote the above was
`I don't quite know what you mean, but for all the plausible things I
can think of virtual packages work better.'
> 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.
If you don't think that what we're doing is workable, propose, get
consensus on and implement something better. Remember the old USENET
maxim: if you want something done, do it yourself !
> 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.
I have gone back through my mail archives, and I can't find any
detailed discussion of what precisely you want dpkg to do.
In a lot of your messages you have asserted that `file-level
granularity dependency and conflict handling' would help with some
problem or other, but it never seemed that way to me.
There is a lot of room in dpkg for fairly sophisticated handling of
individual files at installation and removal time, though taking into
account information at the level of a single file is well-nigh
impossible for dselect for the reasons I've given above.
Prompting in the middle of an `unpack' operation is best avoided,
though, as there is too much chance of something going wrong and
things being left in a kind of halfway in between state.
If you have concrete general proposals, or even specific examples of
what you think dpkg should do to solve some specific problem (like the
`vi' issue above) I'd be interested to hear them.
Ian.
Reply to: