Re: changelog vs ChangeLog and policy dictates
On Sun, 12 Apr 1998, Anthony Towns wrote:
> On Sat, Apr 11, 1998 at 08:57:49PM -0400, Dale Scheetz wrote:
> > On Sat, 11 Apr 1998, Juan Cespedes wrote:
> > > On Sat, Apr 11, 1998 at 04:36:14PM -0400, Dale Scheetz wrote:
> > > > I am not on the policy mailing list, so please cc me on this thread.
> > > > Does/Should the policy manual detail which letters may, or may not, be
> > > > upper or lower case?
> > > I think so.
> > I know ;-)
>
> I tend to also. One of the things I like about Debian is its consistency --
> packages tend to follow the same rules. Having one package have
> /doc/x/ChangeLog, and another /doc/y/CHANGELOG, and a third /doc/z/changlog
> would mess that up somwhat, IMHO.
>
> My other inclination is that since Unix's filesystem *is* case sensitive,
> when you specify a filename, you're specifying a specific case of that
> filename.
I completely understand this rather rigid interpretation of Policy, and it
is the rigidity of the attitude about things that are "written in Policy"
that worries me the most about its application.
It was my understanding that the Policy documents were a set of
guidelines. That is was desirable that we all follow these guidelines in
the general sense, but not necessarily in every specific case. (I'm not
even arguing here that this is one of those cases)
>
> > What it does, from my point of view as a developer, is to add unnecessary
> > clutter to what was, previously, a straightforward deal.
>
> Would adding a
> ln -s ChangeLog.gz /usr/doc/xyzzy/changelog.gz
> to your rules file as David Engel suggested be acceptable? It complies
> with the letter of policy and doesn't force you to change the upstream
> documentation.
While this solution is esthetically more pleasing it is no less clutter
that a cp -a ... line. Also, from my perspective, it breaks the
"consistency" you are so desperate to obtain. (It does fix the broken
parser, but there are other ways to do that)
>
> > [...] Dpkg is perfectly happy with PACKAGE:, Package:, or
> > package: as the header for a package entry. To make the script function in
> > that environment I made every buffer that was used for comparisons, get
> > built with "tolower".
> >
> > Why are we trying to be more strict than that here?
>
> IMHO, because we're don't have control of the parser here -- the filesystem
> has already been written, and it's case sensitive.
>
Which parser are you talking about? I never proposed rewriting the
filesystem? The above statement makes me more confused by your position.
> > Consistent with what? I prefer consistency with upstream source.
>
> I think consistency of the end system is more important.
And I don't see you this make the system inconsistent...
>
> > I guess that I see no reason why policy on names should, necessarily,
> > demand case identity, and certainly not in this kind of situation.
>
> The other thing, which I neglected to state specifically earlier, was that
> when writing a tool to find a filename case sensitively you can just use
> "fopen()", or its equivalent. When you remove the case sensitivity, you
> need to get a file listing, and "strcasecmp()" every file you find against
> what you want.
>
When trying to find a specific file "case sensitivity" is our friend. When
trying to find all the instances of a particular string (where spelling is
the most important) case sensitivity is the devil who screws up your count
of pakages in the packages file, if you insist on searching in a case
sensitive fashion.
No matter what totalitarian, police state, tactics are taken in a
distributed system like this some packages are going to always fail to
measure up, and the parser fails anyway.
It is the attitude that we must not violate Policy even in such a trivial
detail as the case of letters in a changlog file that I find both
dangerous and unnecessary. If we blindly followed policy on the issue of
stripped binaries, for instance, we would have a non-functional system, as
the loader will not run stripped, and will sort-of/almost work when
partially stripped. (it needs its symbols to load parts of itself)
My concern with this issue is hopefully more far reaching than the one
line of code that I have already added to the rules file. There are other
ChangeLog files distributed in the doc directory of the form
ChangeLog.<package-add-on>.gz. Now, a strict reading of the policy on
changelog files says that the upstream changelogs must be named
changelog.gz.
With reguard to making a link so that both ChangeLog.gz and changelog.gz
exist, is eventually going to trigger someones lint picker because this
discusion was had in the past and it was decided that changelog was the
only proper form that this object can have, therefore all other changelogs
must be removed.
My desire is to see the hard line on these issues from Policy become
blurred a bit more than current interpretation seems to demand. These
(what seem to me to be fairly trivial) issues detract attention from the
more important integration errors that a developer is likely to make.
Maybe all we need is some way to prioritize policy issues, so that some of
the less useful requirements obtain less authority to force change. The
scale could run from "This absolutily must be like this in every case" to
"this is only a suggestion, which everyone seems to ignore in any case".
> Unless we were to specify that changelog's should be one of: changelog.gz
> ChangeLog.gz or CHANGELOG.gz, perhaps. Which seems, to me, fairly pointless
> when you can simply add an ln -s or a mv to your rules file. YMMV. And
> probably does. :-/
Any search utility that doesn't search for those strings as well is
guaranteed to miss some instances of a changelog.
>
> (that said, I am inclined to prefer the symlink approach to the mv approach,
> at the very least that'll keep it reasonably obvious what's going on when
> upstream docs say something like "Please refer to the ChangeLog file
> included with this program", or similar)
>
The only reason to avoid the symlink (which I agree is more elegant) is
that it creates a file in the directory called ChangeLog, which is, in a
strict interpretation of Policy, a violation. (at least it is to someone)
I prefer the latitude provided by a more relaxed interpretation.
> > _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
>
> At a complete tangent, is this online somewhere?
>
You will find it at http://www.linuxpress.com as the top entry on the
page. There is lots of other inforation on the book, including ordering
information, but a 360K html version of the book is available for
download. Just follow the roadsigns...
Thanks for the plug ;-)
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: