Re: changelog vs ChangeLog and policy dictates
-----BEGIN PGP SIGNED MESSAGE-----
On Sun, 12 Apr 1998, Dale Scheetz wrote:
>On Sun, 12 Apr 1998, Anthony Towns wrote:
>> 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)
? Now I'm confused. How does this break consistency? It maintains
it. The "consistency" in question is that by policy, if there is an
upstram changelog, it should always be findable, compressed, in
/usr/doc/package/changelog.gz. This is no different from the Debian
changelog policy, or the copyright file policy, both of which also
specify names.
>> 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.
Erm, let's start with fopen() or anything else that will attempt to
open a file. You can't tell the filesystem to recognize an attempt to
access changelog.gz as an attempt to access all capitalization variants
of changelog.gz. You can't just "tolower" anything here, since the
expected target filename is already lowercase. The problem is that if
that file doesn't exist, you have to manually check for every other
variant. If we decide to allow all variants of capitalization, how do
you expect anyone to find the inevitable idiot file ChAnGeLoG.gz?
>> > 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'll assume this was meant to read "And I don't see how you think
this makes the system inconsistent." The answer is simple: You cannot
go to /usr/doc/package/changelog.gz and find the changelog for every
package. That is an inconsistency, and IMO a bad thing.
>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.
And then bug reports get filed, which is a good thing. Lintian
could help cut down on a lot of this.
>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)
You are comparing a special case scenario where an exception has
already been noted to a general case. Please explain how it will break
your package and/or the rest of the system to add a symlink. Certainly,
if someone can demonstrate this, an exception could be granted, much
like other aspects of policy. So far, nobody has demonstrated to me,
anyway, any such reason. Regardless, neither the existence of a loader
that cannot be stripped nor the existence of a changelog.gz file that
must be named ChAnGeLoG.gz for whatever reason changes the idea that
it's a good thing to strip binaries, or that one should be able to find
the changelog in /usr/doc/package/changelog.gz
>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.
No, a strict reading of the policy says that displaying changelog.gz
must display the upstream changelog. There's a difference.
>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.
*stare* Where in policy does it dictate what files can be placed in
/usr/doc/package? I can see someone forcing you to change a copied
version to a symlinked version to save space, but that's under space
conservation and a different part of policy.
>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.
So we make it a Lintian check, and all is well in the world. It's a
little bit like the accepted policy of making files 644 and directories
755. Easy to miss, kind of trivial, really, and pretty trivial to
correct if they get noticed. So they got put in Lintian, and most
people don't have a problem with it.
>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".
If you think about it, there already is one, built into the English
language. All you have to do is propose a change in policy to have
something read: "It is suggested, but not required, that ...".
Certainly, however, if you proposed that in this case I would oppose it.
>> 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
>
>Any search utility that doesn't search for those strings as well is
>guaranteed to miss some instances of a changelog.
Which is a pretty good reason in my mind to implement checks, not
force all search utilities to search all possible strings.
>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)
Again, I don't think it is a violation to anyone.
"If there is anyone out there who really believes this, speak up
now, please!"
So now, if someone complains about it six months down the road, we
can refer them to this posting, and ask them why they didn't speak up ;)
=============================================================================
Zed Pobre <zcp@po.cwru.edu> | PGP key on servers, fingerprint on finger
=============================================================================
-----BEGIN PGP SIGNATURE-----
Version: 5.0
Charset: noconv
iQEVAwUBNTEVY9wPDK/EqFJbAQEoIAf/V2PHRCJh3PQS+Tj4KnVjTkJdiTv3nLSc
d6aKBcG1Ny/9VQCvxw4FkJzPBRK7X5Ym+3jmU6AlvnFhbP00uQXkS/4ZgC8H+RT1
D/4/AduCMC1vdXtttrN03S1g9pm3K5+lU47WMfK8j3KVWMmrWXrSBV8cRrf6rK3b
ImNOsOVb+fGsbrASa3bTZI+AJ81jfID95y1q7UsY1gRPTkt/PV3Jxv52lHnAgvjW
Xf1kub+wc4wo316rL2vp6o/bLJ5oFypyJMtUaQUM+Cb3Hptbb7FaV7kWE5Tf7SRg
nZ5Kp7zWeDdGv3DNxw28lIc3si4pZ/w++3lrSsHwtuJdWk3g5j9GyA==
=7RV0
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: