[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: O: Gnus -- A versatile News and mailing list reader for Emacsen.

On 25 Apr 2006, Bernhard R. Link verbalised:

> * Jorgen Schaefer <forcer@debian.org> [060425 14:34]:
>> The discussion is about whether, after the removal of data from an
>> upstream .tar.gz, it is ok for it to be still named ".orig.tar.gz"
>> (with a version that does not exist upstream). 
> The question I was answering was about what I consider "fork".
>> One side of the dispute says ".orig.tar.gz is just a package we
>> name to mean 'well, that's roughly what upstream put in it, we
>> didn't add anything, but maybe we removed something". The other
>> side thinks that's somewhat unfair to the user, and says "if we
>> call it foo_1.3.orig.tar.gz, it damn well should be _exactly_ what
>> upstream released as version 1.3 of foo. If we modify what's in
>> there, it's not enough to create a new version -
>> foo_1.3dfsg.orig.tar.gz - but to rename the base name there, to
>> make it clear it's not foo, but some variation thereof -
>> foo-dfsg_1.3.orig.tar.gz".
> That's not the whole alternative. I think a .orig.tar.gz should
> only contain stuff that upstream released. For everything else
> there is the .diff.gz.

        On what basis are you making this decision? I explained that
 it is important, for debugging and development reasons for the free
 software community, to be able to easily build upstream versions to
 see how it compares to the debian patched version of the software, so
 if the maintainers hacking in .orig breaks the build system, the
 system should be fixed.

        So far, all you have offered is an opinion to the contrary. Do
 you have anything else?

>> Should Debian enforce a policy here? 
> There is a Developer's reference quite explicit about that topic
> and all those packages beside his.

        Developers reference is not policy.  It is best practices, and
 guidelines, but like any general guide, one should not follow
 blindly, but look at the case to see if it still applies. 

        I have explained when the package ought to be considered to be
 closer to a fork than repackaing in an earlier email.  Make and Gnus
 are forks.  Just ask the upstream, it is not merely my opinion.

>> If so, who decides on what the policy is? Surely not the
>> ftp-masters.

> I guess it would be less of an issue, if he did not insist of what
> almost everyone else has agreed on and I never saw disputed is
> "unethical".

        Ah. Your technical and policy decisions are biased by my
 belief that some practice is unethical, as opposed to the merits of
 the issue in your eyes? I see. I now know better how to categorize
 your opinions, then.

He who foresees calamities suffers them twice over.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: