Source packaging arrangements (was Re: Debian vs. BOGUS)
Bill Hogan writes ("Re: Debian vs. BOGUS "):
> As I see it, Debian users have the following situation:
> [ diagram deleted ]
No, the situation is as in my diagram below.
In particular, the Debian changes and the original files are not
usually `merged' by the Project, except when the original package is
updated.
> I think the point Karl has been making is that while this makes it
> nice for people who do not have to worry about what is in the original
> materials, it does not make it so nice for someone who, say, for some
> reason has to remove some function F from the original materials and
> replace it with a 100% clone F' because, in fact, it is not possible
> to guarantee that what comes out of Process 1/A will be identical to
> the original material.
What comes out of applying the diff backwards will be the same as the
original material apart from the existence of a few empty files
(usually debian.*) - any files that the Debian maintainer added will
appear as empty files, because patch doesn't have a way to record the
creation of a file as opposed to merely a change in contents (creation
is recorded as the insertion of all the contents).
Most Debian packages don't modify any of the source code of the
originals; where they do they do so to fix bugs and other problems.
> I feel more comfortable with the second picture than the first
> because to not deliver the original materials intact seems to me to go
> against the grain of the rule of education and research that enjoins
> us to hew to the primary sources.
This is not `education and research', this is software engineering.
> Moreover, one might argue, because the `.deb' file ultimately
> produced is the same in either case, and because the vast majority of
> Debian users will be using only `.deb' files, why not deliver the
> original materials intact and leave it up to the interested user to
> apply the Debian diffs or not as they choose?
I have spoken to many people about Debian, and the fact that I could
say that we make available the actual source code used by the
maintainers to build the packages in an immediately useable form has
been a very powerful argument.
> I think that is a nontrivial question and for that reason I hope
> Debian reserves the right to reconsider its policy regarding this
> matter at some time in the future.
I am strongly opposed to changing this policy.
Ian.
Note that the distinction between user and package maintainer doesn't
show up well in the diagram below. This is because Debian doesn't
have a strong distinction between the two. This is a very important
feature - any user can easily take on the role of a package maintainer
whenever they feel like it, and either use their efforts themselves,
distribute them locally, or give their contribution back to the
Project.
The `main stream' of package development is doubled below.
original materials
from original FTP site, newsgroup archive, &c
hello-1.3.tar.gz
||
++
//===========// \__________________________
// \ \
|| | |
VV | |
+=====================================+ | |
| Debianisation - | | |
| Package maintainer writes debian.* | | |
| scripts, adds code, fixes bugs, &c | | |
+=====================================+ | |
|| | |
|| ________________ | |
|| / \ | |
|| | | | |
|| | V V |
|| __________|____ +----------+ |
||/ | \ | diff -ru | |
OR | | +----------+ |
|| ^ ^ | |
VV | | V |
Debianised source tree | | Debianisation patch |
hello-1.3-4.tar.gz | | hello-1.3-4.diff.gz |
|| ^ ^ | |
++ | | + _________/
||\__________/ | ______/| /
|| | | | |
|| ^ | V V
|| | | +----------+
|| | | | patch -p |
|| | | +----------+
|| | | |
|| \____|_______/
|| |
++ |
||\_________________ |
|| \ |
|| | |
VV V V
+---------------------+ +-------------+
+ debian.rules binary | | patch -r -p |
+---------------------+ +-------------+
|| |
VV V
Binary package source package with Debian modifications
hello-1.3-4.deb removed, but with a few extra empty files
(and .orig patch backup files).
Reply to: