Re: Conflict/dependency granularity
Bill Mitchell writes:
>Presumption 3 - In many cases, presumptions 1 and 2 will remain
> true long after initial debian installation,
> and perhaps for as long as the system is in
> operation. The system operator will be more of
> a user than a sysadmin. He'll want the system
> for the user capabilities it provides. He'll
> consider system administration as something he
> must cope with in order to support his user
> role. He won't be a skilled unix sysadmin,
> and will not want to invest significant effort
> in becoming a skilled unix sysadmin.
[...]
>If the operator installs a program into /bin, debian may
>silently overwrite or remove this program behind-the-scenes.
I think that in all of the quoted text above, you could be
underestimating the intelligence of operators. More importantly, we
should also be working on the assumption that a production system will
ship with documentation explaining all this stuff; and defending (as
it were) against people who don't read the docs is ultimately
impossible anyway.
Oh, and presumption 3a seems to be ``The operator is male.'' ;-)
>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.
>I think that debian needs to be more tolerant of operator
>action in these cases. I don't think files installed by the
>operator should be silently overwritten or removed by debian.
>I think debian should be considerate of the operator in these
>situations, and seek the operator's acquiescence before
>overwriting or removing his files.
I think we should go no further here than making it clear that
/usr/local is the right place and anywhere else is wrong. If people
don't read the documentation then they'll most likely screw up some
other way as well - and having dpkg overwrite their programs in /bin
(which, being insufficiently clueful to read the docs, are probably
full of bugs and installation errors) will be the least of their
problems.
>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 (not so broken) version
>of /usr/bin/fmt. Elv-vi properly declares a conflict with
>textutils (textutils does not declare a conflict with elv-fmt,
>which could be a problem if textutils were not a part of
>the base section). Installation of the alternate version of
>/usr/bin/fmt and related files from the elv-fmt package can
>be forced by those sufficiently knowledgeable to do so, but
>subsequent upgrading of the textutils package will silently
>overwrite the files installed by the elv-fmt package. This may
>come as a suprise to users who later find that the fmt program
>has become broken or otherwise changed its characteristics.
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,
>Example #2: The cpio package provides /usr/bin/mt. Following
>some discussion that this program may be broken or inadequate,
>the mt package was fielded to provide an alternate version of
>/usr/bin/mt for evaluation. Neither of these packages currently
>declare a conflict with the other. The cpio package may be
>installed, and then the mt package installed to obtain the
>alternate version of /usr/bin/mt, but this alternate version of
>/usr/bin/mt will be silently overwritten if the cpio package is
>upgraded. If these conflicting packages declared their conflicts
>with one another, and if the installation of the mt package
>was forced to obtain the alternate /usr/bin/mt version, the
>mt package would need to be removed or installation of the
>cpio package would need to be forced in order to upgrade
>the cpio package, after which the reinstallation of the mt
>package would need to be forced if the alternate /usr/bin/mt
>version is desired. (Note also that if cpio package upgrade
>is forced, the mt package will be shown as still installed
>since the file /usr/doc/copyright/mt file will not have been
>overwritten during the upgrade of the cpio package, and dpkg
>will not have automatically and silently purged the mt package.
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.
>There may be other examples. Perl may be one. Perl is
>required by the debian base system, and a skeletal perl
>installation is provided by dinstall. However, the perl
>package is not currently part of the base system. The perl
>package may be installed and (horrors!) removed. This may
>indicate a need which I'll mention here but not explore
>further for a means by which a list of special-case essential
>files can be communicated to the package admin system to
>prevent inadvertant removal of essential files during package
>admin operations by the operator.
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.
>With Virtual dependencies, packages may declare that they provide
>some "capability" (I'm not sure of the proper terminology here).
>Packages can then say that they depend on the presence of a
>package providing a desired capability instead of on literal
>package names. This implies some degree of coordination between
>package maintainers regarding the naming of capabilities, and
>regarding precisely what a named capability provides.
I think debian-devel would suffice for this purpose.
>Package dependencies tend to be a problem when packages are
>renamed. Packages end up declaring dependencies on named
>packages which have become obsolete and no longer exist with
>the declared dependency name in the current distribution at
>some point in time.
>
>Virtual dependencies have a coordination problem, and may
>end up having a naming problem similar to that seen with
>Package dependencies if the mapping and meaning of capability
>names changes over time as debian evolves (as seems not
>unlikely).
It strikes me that virtual packages are in fact precisely the solution
to this problem - did you have any examples in mind?
>Both Package dependencies and Virtual dependencies are useful,
>but neither seems to be a panacea.
>
>It may be that there is another alternative in dependency
>administration which, though also not a panacea, could have
>some usefelness -- call it File dependency. This would be
>the ability for a package to declare itself dependent on the
>presence of some particular file.
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.)
>It may be that there is still another alternative in dependency
>administration which, though also not a panacea, could have some
>usefelness -- call it Capability dependency. This would be the
>ability of the system to execute a shell command declared as
>a Capability dependency during package installation and have
>this command exit with a status of 0. This should be approached
>with caution, however, since the command could be a destructive
>one (e.g., "rm -rf /*"). Perhaps it'd be workable for debian
>systems to have an inbuilt system userid with low privilege
>which would be used to execute Capability dependency commands.
Without stating an opinion on whether something like these capability
dependencies should exist:
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?
2) Could one not do what you want to do here in a preinst script
anyway?
ttfn/rjk
Reply to: