Re: Bug#1187: Various `vi' versions trample on each other.
iwj10@cus.cam.ac.uk (Ian Jackson) said:
> > 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 ?
I'd think of that as a special-purpose hack -- necessary only because our
package admin tool doesn't have a good set of general file-granularity
rules. I'd rather see the time and effort put into file-granularity
generalization than into such special-purpose hacks. However, that said,
I'd also think a centralized hack such as this would be preferaable to each
separate maintainer doing his own hack in the install scripts, and
all doing it differently.
Before you do it, could I ask that you describe the intended operation
in debian-devel, offering the opportunity for discussion?
> It's not clear to me that
> (a) you understand in detail the way dpkg operates at the moment
I'm sure I don't. There have been some changes, I know, and it's gotten
a lot more complicated. I never did take the time to figure our all
the dppg --various --options --and --modifiers.
- digression (I wish I could find the article where I read this) -
I once read an article which talked about 1950's era television
sets (I'm old enough to relate to that on a personal level).
In the 1950's, there would be five or six knobs on the front
of the set, and a little door with another five or six screwdriver
adjustments. There would also be perhaps ten screwdriver adjustments
on the back of the set with exotic names like "sync buzz".
Engineering refinement has eliminated that over the years in
consumer TVs. I think dpkg is still in the "sync buzz" era,
with too many knobs to twiddle.
> or
> (b) you have a clear and detailed idea of the way you'd like things
> to work instead.
I have a clear idea -- it's just been a year or so since I articulated
it or thought about implementation details. Things are a bit
fuzzy from having been out of mind for so long. I'm honest enough
to admit that this is the case. Things were less fuzzy a year or
so ago. There were even private implementation-detail discussions
going on in between debian-devel flamewars over the issue. That
fell apart when several people left the project. An attempt to
revive the implementation-detail discussions between you and I
didn't get far.
> > 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.
We disagree. I think we have a different view of the requirements, for
one thing.
>[...]
> 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.
The aforementioned discussions took place pre-dselect, and no thinking
has gone into how to deal with dselect-like concerns. I think, though,
that you're a bit too quick to dismiss the problems of how to deal with
this as "clearly" unsolvable.
[... I'm skipping over quite a lot here -- either because it's becoming
more detailed than I want to deal with in an offhand manner, or because
it's getting close to areas which ignited flamewars in the past and I
don't want to waste time repeating that ...]
> `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,
Regarding virtual packages, I'm not sure precisely what we are doing.
I think I understand what dpkg does about this, though I haven't seen
it written down in a while and didn't retain a copy of the last description
I saw go floating by. I'm not sure, though, precisely how use of
virtual package names by individual real packages is being coordinated.
My impression is that nothing much is going on.
> propose, get
> consensus on and implement something better. Remember the old USENET
> maxim: if you want something done, do it yourself !
I've proposed -- and the ensuing discussions of implementation got lost
in flamewars of such intensity that technical points were obscured.
Offline technical discussions fell apart when people left the project
in the aftermath of the flamewars. I did implement a first-cut alternative
packaging toolset and package file layout using ar(5) format, and did
it after pre-discussion with you about dpkg and dpkg-deb compatability.
That's since been rendered incompatable, you've said, by changes in
dpkg.
I've poured a lot of time into this, and I'm willing to pour more in.
I'm not too motivated, though, to pour more time down the drain.
I remain convinced that we're doing this wrong, that we could do it
better, that we'll need to do it better if debian ever achieves success
(ever more doubtful, I think, as other distributions come to market
around us, wnd we stay in perpetual "RSN" state), and that we could
provide a graceful migration path. I'm more than willing to put time
into working out the details, but it needs to be done in an environment
which is not hostile to change in this area.
> [...]
> I have gone back through my mail archives, and I can't find any
> detailed discussion of what precisely you want dpkg to do.
A lot of that discussion took place offline, and didn't involve you,
since you'd been very antagonistic in debian-devel discussions.
I could dig back thru what email I've kept, and/or just start the
discussions over and let them develop. I don't think debian-devel
is the best place to do this, though. I think there used to be a
debian-dpkg list, and it'd be far better, I think, to move the
discussion out of the mainstream by shifting it over there.
It'll probably generate more volume on this specialized topic
than should be dumped into debian-devel.
> 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.
I think I see the requirements as being somewhat wider than you do.
Some of what I've proposed is aimed at the wider requirements I see,
and I think you've seen the parts not targeted specifically at your
view of requirements which led to the present dpkg as unjustified.
> 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.
I'll think about it. If I can articulate this in the context of something
close to my (somewhat outdated -- I haven't kept up) understanding of
current dpkg operation, I'll get back to you privately.
If there's interest beyond the two of us in starting up a separate
discussion about package admin system issues, I'd be interested in
participating in that. I think it's past time to go back to square
one and re-examine requirements to be sure we have a consensus about
what the requirements are without regard to what dpkg and friends
currently do -- then to take a look aat what, if anything, needs to
be done to address any currently unaddressed requirements which we
identify.
Perhaps it's just because I've been viewing it as a dpkg outsider,
but it does look to me that much of the development has been driven
by looking outward from what's currently done rather than inward
from what needs doing. (or is that too obtuse?)
Is more discussion about this on debian-devel useful? I'm doubtful
about that.
Reply to: