Re: miscutils snag/questions for all
On Sat, 25 Nov 1995, Bruce Perens wrote:
> We should encourage authors to package their programs individually rather
> than dump them on Rik. Sometimes, we're going to have to make judgement
> calls.
And someone commented that it'd have been better if all the programs in
upstream digest packages had been packaged per-program so that we could
pick and choose (my paraphrase).
Is there anything stopping the debian maintainer of an upstream
digest package from breaking each program out into a separate
debian package?
Even if that is done, are the current dpkg mechanisms able to cope
well with multiple alternative packages -- especially those providing
essential files (executable and otherwise)?
Regarding breaking up digest packages, Ian J. said, on this thread:
+ Be careful about splitting a base package up. You can't install two
+ packages simultaneously, so there's a risk of someone replacing the
+ big miscutils with a small one and having none of the programs that
+ are in other packages in the new scheme left.
+
+ There are a variety of ways to deal with this - I'd like Jeff to tell
+ me what he'd like the new package structure to look like so that I can
+ advise him how to get from here to there.
I think we need a good way to deal with this general situation
which is simple enough to use not to need guru advice from
the dpkg designer.
Take the noncritical fmt program for example. It's provided
by the base section textutils program and the editor
section elv-fmt program. These packages, however, don't
declare conflicts with one another because dpkg would (so
I understand) will refuse to remove the textutils package
anyhow if it were declared essential in its control file,
or would break the distribution by de-installing the whole
textutils package in favor of elv-fmt if elv-fmt declares
a conflict with texutils and textutils does not declare a
recipricol conflict and does not declare itself essential.
(I may misunderstand this somewhat. I don't pretend to fully
understand all the special-case handling done by dpkg, However,
I know that I did once break my system by installing an elv-vi
package which declared a conflict with textutils).
A similar situation exists between the cpio and mt-st packages.
Cpio is a digest package which provides both cpio and mt.
It would make no sense for mt-st to conflict with cpio because
of the mt program, since users often want both the mt program
from the mt-st package and the cpio program from the cpio
package.
Both of these situations are currently handled by declaring
no conflicts. The packages overwrite one another, and users
must do housekeeping completely outside of dpkg by assuring
that the program providing the program alternatives they desire
to install are installed last, and by re-installing packages
containing desired programs if an upgrade of a (undeclared)
conflicting digest package overwrites desired files.
The update-alternatives script, currently used only by non-base
section vi clones tries to do deal with this sityation. However
it's very easy for the maintainer of a package providing any
one of the alternatives to break its functionality by simply
not using update-alternatives for his particular alternative.
It's also difficult enough to use correctly and seldom
enough used that it's very easy to get its usage wrong, even
leaving aside the fact that it needs _all_ the maintainers
of intersecting alternative packages to coordinate among
themselves a relative priority ordering of the alternatives
which is to be imposed on debian users, and such coordination
is difficult to achieve and maintain.
Personally, I think our conflict and dependency handling should
be at a file granularity instead of a package granularity.
I've made that argument several times, and been argued down.
I won't make the argument again just now, except to opine that
messy situations such as described above are a consequence of our
package-granularity conflict and dependency handling.
But I digress. I asked rhetorically if the current dpkg
mechanisms are able to cope well with multiple alternative
packages, especially those providing base section programs,
even if the programs are broken out as separate packages.
I think not.
Some thinking about this quickly produces ideas for possible
approaches for addressing it. However, I don't think proposals
(especially embryonic proposals) are called for at this point.
First, there needs to be a consensus that the issue needs
dealing with and, since it's a dpkg issue, there needs to be
buy-in from Ian J.
Do we have a clean mechanism for dealing with conflicts
such as those between cpio:mt vs. mt-st:mt, textutils:fmt
vs. elv-fmt:fmt, miscutils:fdisk vs. standalone:fdisk? Do we
need one?
If the digest package complication is dealt with by breaking
at least some conflicting groups of related files out into
separate standalone packages, do we have a clean mechanism
for dealing with conflicting standalone packages involving
essential files (e.g., standalone1:fdisk vs. standalone[2-n]:fdisk)?
Do we need one?
Reply to: