Bug#824495: debian-policy: Source packages "can" declare relationships
Sean Whitton writes ("Bug#824495: debian-policy: Source packages "can" declare relationships"):
> On Thu 08 Nov 2018 at 02:51PM GMT, Ian Jackson wrote:
> > Or to put it another way:
> >
> > Package builds MAY be influenced by the presence in the build
> > environment of additional packages, beyond the Build-Depends and
> > build-essential. However:
> >
> > Additional packages MUST NOT have any effect other than either:
> >
> > (i) a failure of the build, in which case the additional packages
> > MUST be declared in Build-Conflicts); or
> >
> > (ii) output packages with additional features or functionality.
> > Such additional features MAY imply additional functional runtime
> > dependencies, which then SHOULD be represented in the output
> > packages' metadata. In this case the additional packages
> > SHOULD NOT be declared in Build-Conflicts.
> >
> > Additionally, in any case: additional packages which are installed by
> > default by apt when the build dependencies are installed MUST NOT
> > have any significant effect.
>
> Do we really want (ii)? It seems like a recipe for all sorts of
> confusion. Do any packages currently work like that?
>
> In order to implement something like this, we'd need to rebuild the
> archive on a "development workstation" to confirm we weren't making a
> lot of packages RC-buggy. (It is not clear to me that such packages
> would be considered by most Debian participants to be RC-buggy in
> advance of a Policy change like this one being proposed.)
I am confused. In your first paragraph you seem to be suggesting
deleting my (ii). The result of that wold be to declare rc-buggy any
package which currently falls into my (ii).
In your second paragraph you seem to be shying away from declaring
anything rc-buggy. But you refer to a "development workstation" and
the text from my proposal which mentions that is this:
> > Any additional package which could reasonably form part of a
> > default install for a development workstation SHOULD NOT have any
> > significant effect.
That's just a SHOULD NOT. So what I am declaring buggy is the
behaviours that you and Simon seem to be objecting to - only I
restrict the bugginess to "development" packages.
The reason for this rule is practical: the point is that you SHOULD be
able to rebuild a package "well enough" for use, without needing a
chroot etc.
Can I suggest that the best way to think about this may be the tabuler
form of my proposal ? Lookng at individual rows there (including
their definitions and my proposed consequences) may be easier than
trying to figure out what people mean when they say "are we sure we
want (ii)" when (ii) is an exception to a conditional prohibition.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: