Hi
>>"Martin" == Martin Mitchell <[EMAIL PROTECTED]> writes:
Martin> "Christian Hudon" <[EMAIL PROTECTED]> writes:
>> Right now, I cat the files together in the right order and install
>> the result as /usr/doc/lynx/changelog.gz It's consistent with other
>> Debian packages, and it allows the whole thing to be extracted
>> automaitcally by a script.
Martin> Consistent with other Debian packages, but not necessarily
Martin> consistent with the other documentation in the package.
Huh? What does that mean? How can concatenating Changelogs
that have been split up upstream make it inconsistent with other
documentation?
Martin> I think here you could symlink changelog.gz to CHANGES2.8.gz
Martin> only. After all, unless you're a lynx developer, do you really
Martin> wish to see such a long history?
Why not? Does that mean that I shouyld split up/truncate a
long CHANGES file from upstream on the basis that long changelogs are
uninteresting? If not, why not?
Martin> Alternatively, I think you could provide one cat'ed file, as
Martin> you do now, and install CHANGES* as well.
Duplication.
Martin> With your current system it's a major change to the structure
Martin> of the original documentation - I don't think it is
Martin> appropriate for a package maintainer to be changing the
Martin> upstream source so significantly.
I tend to disagree about the significance of this
change. I think this is well within the purvue of what a maintainer
does.
>> Am I the only one who thing this symlink idea ('preserving the
>> upstream changelog name') is just a needless complication?
Martin> It isn't a complication. It is designed to provide consistency
Martin> for both the whole Debian system and each individual package.
I personally am not convinced of the "consistency with the
package" idea. Remeber, we do significantly change package to
conform to policy (for example, all configuration files in /etc rule,
and other things to do with the file system structure)
Martin> I haven't seen a path mentioned too often in docs. However
Martin> sometimes the top of a README contains a list of doc files
Martin> that should come with the package. If you change the names of
Martin> some of those files, or combine some of the files into other
Martin> files, it looks quite inconsistent.
The solution, obviously, is to change that list to be consistent.
manoj
who does not think one size fits all in this case
--
"Now, telephone companies are not stupid, at least for large values
of 'stupid'." Michael O'Brien (Mr. Protocol)
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
