[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#240665: [PROPOSAL] require depending on split-off packages



On Sun, Mar 28, 2004 at 06:31:38PM +0200, Andreas Barth wrote:
> Package: debian-policy
> Version: 3.6.1.0
> Severity: wishlist

> we had some discussion the last days about whether a package must depend
> on a split-off package.

> I herby propose to add a section 7.5.3 to the policy with the words:

> 7.5.3 Moving files or functionality to another package

> If some functionality is moved from one package to another (also at
> splitting off a package), the first one must depend on the second for
> the time of at least one stable release. By this, no functionality is
> removed on dist-upgrade.

For the record, I disagree with the idea that this merits a "must" in
policy.  Packages shouldn't be split gratuitously in the first place,
so if a maintainer feels a package split is appropriate, this clause
means the benefits of doing so would not be seen for a full stable
release cycle.  I think package splits are best left to the maintainer's
discretion; public outrage will set things straight soon enough if the
functionality being split off is really all that important.  I don't
think I would object to this being a "should", however.

To take as an example the package split that prompted this proposal: the
sendmail package recently split off the rmail binary into a separate
package.  Now, AIUI, rmail is useful to a very small subset of users;
specifically, to those using uucp.  As it happens, the bug report
against sendmail complaining about this split came through the uucp
maintainer.

But uucp did not depend on sendmail at all, it only declared a
dependency on mail-transport-agent, a virtual package also provided by
other packages that don't contain an rmail binary; and it's been
suggested that this is not an RC bug in uucp, because the rmail
relationship ought to be a Recommends:, not a Depends:.  Therefore, I
believe it's important to grant the maintainers some latitude in
deciding how to resolve this (hmm, with the tech ctte's if necessary,
eh?).

-- 
Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature


Reply to: