Re: Conflict/dependency granularity
On Sun, 6 Aug 1995, Richard Kettlewell wrote:
> Bill Mitchell writes:
>
> I think that in all of the quoted text above, you could be
> underestimating the intelligence of operators.
Not so much underestimating their intelligence as making a
judgement about their inclinations. I know quite a few
intelligent people who use a Sun workstation at work and
MSDOS & Windoze based systems at home and have no idea of
how to deal with unix admin at work (someone else sets up
their login account, and they don't need or want to deal
with that), or MSDOS or Windoze admin at home (don't know what
config.sys is for, etc. -- the system came preconfigured and
they install and use shrinkwrapped applications). They're
effective with applicatiions, but don't know much about system
administration, and don't want to know. They just want to use
the machine as a tool. They don't want to maintain the tool).
What we're doing with our packages is analagous to what's done
in the DOS/Windoze world with shrinkwrapped applications, but
complicated by dependencies between our packages and conflicts
between packages we provide and with packages and applications
provided by others.
> Oh, and presumption 3a seems to be ``The operator is male.'' ;-)
Please take all references to 'he' to mean he/she, gentleperson.
> >If he installs this program into /usr/local/bin, but it depends
> >on files which he must install into /etc or /usr/lib, debian
> >may silently overwrite or remove those files. An operator who
> >has installed a program which he himself did not build from
> >source may easily find himself in this situation.
>
> /usr/local/lib exists. /usr/local/etc might also be the right place
> to use here, tho I'm not sure.
and
> I think we should go no further here than making it clear that
> /usr/local is the right place and anywhere else is wrong. [...]
But if he/she is installing an application which (s)he received in
binary form only, the operator-person may find that it's built to
look in e.g. /usr/lib, not /usr/local/lib.
> >Example #1: The textutils package, part of the debian base
> >section, provides /usr/bin/fmt. This program is broken (it
> >may have been fixed, but its brokenness is not central to this
> >point). elv-fmt provides an alternate [and the user installs
> > it that, with complications which are discussed]
>
> The problem could be solved by fixing the /usr/bin/fmt in textutils,
> which (without having looked at it) ought to be easier than inventing
> and implementing new schemes for package management,
and
> Again, it should be easier to fix cpio - e.g. by persuading its
> maintainer to include the alternative version of mt - than to invent
> and implement fancy new schemes.
The point, though, was not the brokenness of textutils fmt and
the possible brokenness of cpio mt, it was the complications which
grow out of using the alternates. You seem to be arguing that
no alternates should be provided in the distribution unless they
are alternates on a package-granularity basis, and that we should
not support use of such alternates. There lies the realm of
"undefined behavior" [insert Twilight Zone theme].
> >[Perl]
> Yet again, either moving the rest of perl into the base or adding
> appropriate dependency lines to packages which need more than a
> skeletal perl seems far easier than any other solution.
I haven't looked at what may be behind this. Possibly package
size has something to do with it. Another example in 0.93R6 is
/usr/lib/terminfo from dinstall and from ncurses-runtime. I
think the solution which has been discussed is to make the
packages involved part of the Base section, to only provide
skeletal installations with dinstall and mark the packages
not-installed, and to arrange things so that Base section
packages cannot be removed once they are installed. I'd
characterize that as a hackish solution, necessitated by
dpkg not currently being able to deal with file-granularity
issues in a general manner. However, what's hackish to one
person may be an elegant solution to another.
> >Virtual dependencies have a coordination problem, and may
> >end up having a naming problem [...]
>
> It strikes me that virtual packages are in fact precisely the solution
> to this problem - did you have any examples in mind?
Not yet. There aren't many examples of the use of Virtual package
dependencies around. I was projecting expectations here from what's
taken place with plain packages -- with some packages having been
fragmented, rearranged, and renamed before reaching their current
state, and no guarantee that their current arrangement or naming
is set in concrete. I don't think we have a good definition yet
of what the set of virtual packages is to be, or what capability
each will provide. I'd be wary that the first definition we come
up with might not be stable for all time. I'd not be suprised
to see rearrangements and renamings.
One issue which I didn't discuss is backwards compatability. Once
several debian releases with collections of packages are floating
around, there'll be attempts to install new packages to systems
with an older installed-package population, and older packages
to new systems. Virtual packages will help out there, but I
doubt that it'll be a silver bullet. It won't help, for example,
in the case of a package version from before the appearance of
whatever virtual package it needs to be declaring a dependency
on, or the installation of a new package depending on a recently
appeared virtual package name onto a system populated from before
the appearance of that virtual package. File dependencies might
be a solution with fewer problems in some of these cases.
> >[File dependencies]
> You could name virtual dependencies after files, perhaps? (This idea
> needs some development, but it may be the way to go to achieve what
> Bill wants without someone having to do a lot of work on dpkg.)
I'm trying to divorce requirements definition from implementation
concerns here, so that requirements drive implementation, not the
other way around. I'm not suggesting that implementation work
to address any of this begin immediately, I'm trying to get some
needs I see which I think have been overlooked made visible and
considered. I think we should agree what needs debian will and
will not address before we think about how to address them.
I think I stepped outside of that myself in my ramblings about
"Need #5 - dependency and package admin". What that boils
down to is that I've seen instability and coordination problems
with Package dependencies, and I'm not sure how well Virtual
dependencies will do at correcting that. I then plunged on
into the blurry area separating requirements from design and
brainstormed a couple of design approaches under the guise of
requirements statements. Needs more thought, I think. In the
near term, since we're already working on Virtual dependencies,
it's probably best to try to to a stable and effective job there
and see how that works out. Perhaps my suggestions about File
and Capability dependencies will turn out to be solutions looking
for a problem.
> >[Capability dependencies]
> 1) If one wanted to attack a system through a package
> {pre,post}{inst,rm} scripts already provide the route. Why bother
> putting it in a capability dependency?
Good point. Didn't think about that.
> 2) Could one not do what you want to do here in a preinst script
> anyway?
Yes, but then all dependency, conflict, and conffile handling can
be done from {pre,post} scripts. Even so, it's useful to have
consistent, higher-level mechanisms.
Reply to: