Re: Conflict/dependency granularity
On Thu, 3 Aug 1995, Ian Jackson wrote:
> (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.)
Following is some argument for what I see as package admin
system "needs" which dpkg does not currently, in my view,
address adequately. I've approached this by stating a number
of distinct needs, the validity of which may be arguable.
I've provided an argument in favor of the validity of these
stated needs. I've also proposed some package admin system
requirements which, if satisfied, might address these needs
better than I think thay're currently addressed.
----------------------------------------------------
Terminology
Operator - Generally, the person responsible for the system.
Probably the debian installer, system administrator,
and (in many cases) principal user.
User - The operator and other users
----------------------------------------------------
Some presumptions - not all of which are important to the
material which follows, but all of which I believe are
true, are important, and should be kept in mind.
Presumption 1 - Many debian operators will be unschooled in the
fine points of unix system administration
Presumption 2 - Many debian operators will be unschooled in the
fine points of dpkg usage and debian system
internals (e.g., start-stop-daemon, /etc/rc*,
/var/lib/dpkg/*)
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.
Presumption 4 - Many debian systems will be standalone systems,
essentially single-user systems, perhaps
with occasional dial-out connectivity to
other systems.
Presumption 5 - Nonwithstanding all of the above, a large number
of systems will resemble more traditional
unix systems, supporting multiple concurrent
user logins, network connectivity, internet
connectivity, etc.
Presumption 6 - There will be many systems falling in between
those characterised by presumptions 4 and 5,
as well as some with highly individual and/or
non-traditional configurations (e.g., a dedicated
process automation controller).
----------------------------------------------------
Need #1 -- Support all the systems mentioned in the presumptions
above, and try to do a good job of it.
----------------------------------------------------
Need #2 -- Tread lightly on files installed by the operator
We currently have a policy that /usr/local and /home belong
to the operator. This implies the unstated policy that that's
the operator's "turf", that the rest of the system is debian's
"turf", and that the operator trespasses onto debian's "turf" at
his own risk. It's the operator's responsibility, therefore,
to be aware of areas where what he does might conflict with
behind-the-scenes debian system operations, and to deal with
that. This implies good awareness on the operator's part
of considerations involved in dealing with behind-the-scenes
debian system operations. This conflicts with Presumptions
1-3 and, therefore, with Need #1.
If the operator installs a program into /bin, debian may
silently overwrite or remove this program behind-the-scenes.
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.
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.
This situation occurs during package installation, upgrade, and
removal. The package admin tool should be considerate of
operator-installed files. The package admin tool should seek
to be aware of operator-installed files, so as to be able to
know when to ask operator acquiescence before overwriting or
removing them.
----------------------------------------------------
Need #3 - Minimize the need for coordination between package
maintainers
Packages are developed by widely separated maintainers.
Up to the present, the maintainers have been a closely-knit
group and close coordination has been a workable option.
Still, coordination between maintainers has, at times, been
less than perfect. As debian becomes more popular, packages
will be constructed from outside this close-knit group, and
coordination between maintainers of separate packages will
become less perfect than it has been to date.
In order to properly declare conflicts with other packages,
package maintainers must be aware of the internal details of
all potentially conflicting packages -- both those currently
in circulation and those under construction by all other
maintainers. Without close coordination between maintainers,
this is unworkable.
In order to keep conflict declarations current, package
maintainers must be ever-vigilant for the appearance of new
conflicting packages, and update their maintained packages
to declare newly-appearing conflicts. This is unworkable.
This suggests to me that inter-package conflicts must be
determined not by separate maintainers, but at the point of
conflict where packages come together. Packages come together
at two points: at the central distribution site at the time of
acceptance into the distribution, and at package installation
time onto a debian system.
The debian package admin tool supports usage to construct,
distribute, and install packages which never become part
of the central distribution. It is unworkable for conflict
administration done at the central distribution site to deal
with conflicts arising from such packages. This suggests that
conflict administration needs to be done at package install
time on the target debian system.
----------------------------------------------------
Need #4 - Support alternate versions of program and
non-program files
Even between packages in the central distribution, there is
a problem with confict administration between alternative
versions of the same program. This arises out of package
vs. file granularity issues.
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.
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.
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.
====================================================
Needs #2, #3, and #4 above can all be addressed to a large
extent by doing conflict administration on the basis of
conflicts between files provided by a package and files present
on the target system, rather than on the basis of declared
conflicts between distributed packages.
Requirement #1 - Package conflict administration should
be accomplished on on the basis of conflicts
between files provided by a package and files
present on the target system.
====================================================
Need #5 - Dependency and package admin
There is a recognized requirement for a means to declare that
one package depends on another. There is also recognition that
this is not sufficient. A supplemental dependency adminstation
technique, Virtual dependencies, has been implemented to some
degree, but is not yet in widespread use.
With Package dependencies, one package declares that it depends
on a list of other packages specified by literal package name.
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.
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).
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.
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.
Requirement #2 - File dependency support should be provided
Requirement #3 - Capability dependency support should (possibly)
be provided
====================================================
That's it for now. There may well be holes in the above. There
may well be other needs and requirements which I've not identified
above. I think this area would benefit from some discusison.
I think the discussion is likely to be most fruitful if it
proceeds along these general lines:
1. Identify needs. Discuss. Weed out red herrings.
2. State requirements which, if satisfied, would satisfy needs.
Strive to minimize interdependency between requirements.
Discuss. Identify valid requirements.
3. Explore design/implementation options for valid requirements.
Strive for graceful migration for both package maintainers and
(more importantly) system operators.
4. Integrate into the package admin system as upgrades.
5. Unit test. Alpha test. Beta test. Field test. General release.
Reply to: