Bug#587279: debian-policy: section 2.2.1 needs some tweaking
On Wed, Mar 14, 2012 at 1:43 AM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> Opinions are malleable (wrong and right are all a matter of
>> perspective). This is something sufficiently nuanced that I think its
>> worth sufficient pondering to really get it right. If you haven't spent
>> much time pondering those nuances, it's easy to assume perspective of
>> the status quo.
>
> But I have spent much time pondering these nuances and have decided that
> while your opinion makes sense and comes from a set of reasonable
> assumptions, I don't agree with it.
>
> When I said I wasn't interested in reopening this discussion, I really
> meant it.
A little bit of discussion and critical thought is healthy. In fact
alternative viewpoints are very healthy for drawing informed opinions.
I understand you're probably very busy with other things and this is a
bit of a distraction. I apologize for consuming some of your time.
I'm a logical person, so if you can poke a hole in the logic of the
thought experiment above, or even provide a reasoned argument for your
viewpoint, you could probably end my concerns rather quickly. This
"move along, nothing to see here" argument is not constructive.
> My perception is that the project made a decision on this case
> (one that I happen to think is right) and there's no great clamour to
> reopen the topic. You don't agree with that decision, which is perfectly
> reasonable.
The project as a whole rarely makes decisions (except in cases of
GRs). The current status quo is basically the due to the path of
least resistance. Even though the problem remains, no one is doing
anything due to inertia, even though very few oddball packages would
even be affected.
> I think you're in the "rough" of "rough consensus."
It takes some moxie to put a dent into the status quo. If that's
rough, so be it. I try my best to be kind and constructive though.
Really I've tried to avoid anything potentially confrontational for a
long long time now.
> If such a clamour arises, then of course that's a different situation.
Well, there was the recent -devel thread on essentially the same
topic: something like "holes in our software fortress". It's not
going to go away, why not spend a little time to get it right and get
it over with?
> Anyway, I think this is irrelevant to the wording debate, since the core
> of that argument is over what it means to "depend on or recommend" or to
> "require" other software, and that's not something we're going to resolve
> by tweaking the wording.
So, dfsg licensing handles certain odd/esoteric cases by using
thought experiments like the tentacles of evil. My thought experiment
certainly isn't as interestingly titled, but it is something that
could be used to decide these grey-area dependency situations. Sorry
for choosing getweb so much, but that's the best reference point I
have. It's for example purposes. Not because I really even care
about that package.
>> Right, I wasn't trying to say that. My point was more that the lead-in
>> paragraph as it is now is only descriptive, but given the wording
>> doesn't actually lay out any of particular requirements (more so it lays
>> out the ideals of main). The requirements themselves actually start
>> with, "Every package in main must comply...." then continues with "In
>> addition to" and then the bullets.
>
> Yes, this is the point where we don't agree. You feel that because there
> isn't a "must" in the first paragraph, it's not a requirement. I think
> the first paragraph is clearly a requirement, whether it includes the word
> "must" or not. It's typical in standards that statements of fact like
> "nothing in main requires software outside of main to function" constitute
> a requirement placed on software going in main, regardless of whether it
> uses a specific standards word. In other words, you aren't allowed to do
> something that makes factual statements in the policy document false.
I think Ben's rewording would be good.
> (This comes up frequently in descriptions of syntax. It's usually both
> tedious and pointless to add "must" words everywhere to say that people
> aren't allowed to violate the syntax.)
>
> If it would result in less argument, I can support rephrasing the first
> paragraph to include the magic word "must" around "does not require
> software outside of main to function."
>
>> It's not unclear per se, but there remain ambiguities in terminology
>> making it possible to interpret it in various slightly incompatible
>> fashions: the choice of the term "package" vs. "software" makes it
>> appear ok to have non-main "software" depends/recommends but not ok to
>> have "package" depends/recommends.
>
> The reason why I'm somewhat unenthused about tweaking the wording here is
> that there are *always* going to be ways to interpret human language other
> ways, particularly in an area like this that's rife with acknowledged grey
> areas (like emulators that are mostly used to play non-free ROMs but can
> also play the -- often nearly nonexistent -- free ROMs). In other words,
> I'm skeptical whether changing the language here is going to result in
> fewer discussions like this, and whether it's going to actually resolve
> confusion, as opposed to being a debating stick.
How often is this really debated? If its keeps coming up, that is
indicative of a persistent flaw that needs fixing, right?
Maybe its worth considering the potential tradeoff in moving to the
more restrictive viewpoint? There are very few packages that have
these fetching scripts anyway, and they'll simply need to be moved to
contrib. So maybe it would be easier to make the change and cause
some packages to make a few minor changes, rather than continuing to
deal with the consequences of this ambiguity ad infinitum.
Best wishes,
Mike
Reply to: