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?
