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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CANTw=mofrwmmxrhqqvvp0ihl3txz_71oxt1cmhzoy5l2_aw...@mail.gmail.com
