[This bug was closed by the upload of debian-policy I just did, since I
believe that I fixed the problem in the original report.
I do not mean to suggest by this that I think discussion should end. We
can clone and reopen when we have a more concrete change proposal]
Hello,
On Mon 12 Nov 2018 at 01:39PM GMT, Ian Jackson wrote:
> Sean Whitton writes ("Bug#824495: debian-policy: Source packages "can" declare relationships"):
>> 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.
Sorry about this. I was thinking of the practice permitted by (ii) as
something implemented by the Debian package maintainer, rather than
something implemented by upstream in their build system. That's why I
was against any text that seemed to permit a Debian package maintainer
implementing something like that.
I agree that if we implement new rules about when packages beyond those
listed in build-depends and build-conflicts may affect a build, we need
to include (ii) as an exception to such a rule, because plenty of
upstream build systems work this way.
I still don't see how we can implement such new rules, though, because
of the problem of how to determine whether we're making masses of
packages RC-buggy.
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature