Re: O: Gnus -- A versatile News and mailing list reader for Emacsen.
On 25 Apr 2006, Bernhard R. Link outgrape:
> * James Vega <jamessan@debian.org> [060424 18:36]:
>>> On the other hand a different source package name has also a
>>> specific meaning. It means it is a different source package, which
>>> means it is a differnt upstream or a different package. Unless you
>>> want to fork the package or add other files, changing the source
>>> name is deceptive.
>>
>> Isn't it already a fork? The source package is not the same as the
>> one being shipped by upstream. Hence Manoj's desire to use a
>> different source package name to correctly convey the fact that the
>> source package is not what is being shipped by upstream, but a
>> modified version that meets the requirements of the DFSG. How is
>> it deceptive to rename the source package when it is _not_ the same
>> as the upstream source?
>
> For some meaning of fork, every Debian package is a fork of
> upstream.
To avoid getting into a position where nothing meaningful can
be said, one should note that a difference in degree exists, and is a
factor in deciding whether it is "repackaging" or a "fork".
When it comes to excising material from the orig.tar.gz, if
that material has been left in by accident, can be regenerated
automatically, -- then again, the the chances are that it is still
not a fork.
The devil lies in the details: the amount of material
removed, and the significance to tht ematerial removed, as well as
how critical it is to the proper functioning of the software, or the
end user experience, is significant. Removing CVS dirs counts for
far less than, say, removing a pluin infrastructure from the
package.
> Note that in all that cases the .orig.tar.gz only contains stuff
> upstream released, with only files packaged in another form of
> archive or stuff removed, nothing new.
If I gut all .c files from make, can the package still be
called make, really? Yes, this is an extreme example, but it
demonstrates that a blanket statement that "removing files is OK"
without considering the magnitude of the functionality lost or how
the user experience has degraded can be justified.
> Such a stripped down archive will most likely not have a working
> build system and some stale references to stuff no longer contained,
> which can and has to be cleaned up in the .diff.gz (at least for the
> stuff relevant stuff, no need to patch a build script for DOS)
Frankly, that means the original program as shipped is broken,
and the user no longer has the freedom of building upstream's
version and comparing it to the Debian patched one. I think this
loss ofuser freedom is also significant, and nayone shipping a broken
.orig.tar.gz is shortchanging the end user.
> If you in contrast choose to add or modify things in the
> .orig.tar.gz, you are in this (perhaps a bit personally coloured)
> view no longer making changes within Debian, but are creating a new
> fork on the upstream side and are packaging your own fork.
Both make and Gnus fell in this category.
manoj
--
Is this an out-take from the "BRADY BUNCH"?
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: