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

Conflict/dependency granularity

(I think Bill and I should continue to discuss this here until people
object.  If it turns out to be impossible for us to remain civil we
should probably abandon it, rather than taking it to email -
experience suggests that the latter approach doesn't work.)

Bill Mitchell writes ("Re: Bug#1187: Various `vi' versions trample on each other."):
> Before you do it, could I ask that you describe the intended operation
> in debian-devel, offering the opportunity for discussion?

There is a lot of documentation around.

There are several *.txt files I've uploaded to the ftp site, with
descriptions of various parts of dpkg's behaviour, aimed mainly at the
package maintainer.

There is the old dpkg specification document, which I (or someone
else) need to update to reflect changes that have been made.

There is a long and (I hope) clear comment around line 340 of
main/processarc.c, which describes in detail what happens for each
file found in a .deb file's filesystem archive.  In general there are
few comments in main/processarc.c and in dpkg in general, but those
that are there will be accurate and often helpful, and they often give
a much wider picture than just looking at the code.

The dpkg --help message describes the various options, and should be

I posted a series of messages shortly after Christmas about what I
intended to in the new dpkg.  These messages were the result of
extensive consideration of various design and requirements issues.

There have been numerous other postings I have made on debian-devel
about dpkg's behaviour.

I suggest you read all of the above and then come back and ask me
about anything you don't understand.

> > 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.

Try reading the source.  Seriously :-).

> - 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.

dpkg is only going to get more knobs.  I'm afraid that software
doesn't behave like televisions (and in any case a modern television
has a zillion buttons on the remote control for controlling the
teletext, the video recorder, and what have you).

> 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.

The description of dpkg's behaviour is on the FTP site, as
dpkg-virtual.txt or some such.

You appear to be right about nothing going on wrt coordination of
virtual package names.  I think more coordination than we have at the
moment might be useful.  Are you volunteering ?  (You should go and
read the dpkg-virtual.txt or whatever first, clearly.)

> 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?)

I think it's because you've been viewing it as an outsider.  Certainly
I've never posted many of my deliberations, simply because what was
required wasn't a discussion here on debian-devel but rather
consideration of the requirements before posting a proposal here.  If
you don't believe me I'll fax you copies of some of the notes I made.


Reply to: