On Sun, Apr 30, 2000 at 03:27:46PM +0200, Wichert Akkerman wrote:
> We have a couple of different types of entities involved:
> * .sig files for upstream distributed files
This wasn't mentioned further.
> * original upstream sources (one or more tar archives)
> * upstream patches
> * debian patches
> * debianization files
How would these be stored in the archive?
Some possibilities:
foo_1.2.orig.tar [a tar of the (compressed) upstream files]
foo_1.2-1.diff.tar [a tar of the (compressed) debian patches/files]
foo_1.2-1.dsc [signed md5sum of the above two files, etc]
or
foo_1.2.orig.1.tar.gz [the first upstream tarball]
foo_1.2.orig.2.tar.gz [the second upstream tarball]
foo_1.2.orig.3.tar.bz2 [the third upstream tarball]
for_1.2.diff.tar.gz [upstream and debianization patches]
foo_1.2-1.dsc [signed md5sum of the above files, etc]
or what? Where would upstream signatures be kept? How should upstream and
Debian patches be differentiated, especially for Debian patches that get
forwarded upstream? Should debian/* be stored as a diff or as a tarball?
If there's a Debian-specific binary file that has to be included in a
tarball instead of a diff (coz it's binary), should that be stuck in with
the Debian stuff or the upstream stuff?
Hmmm. I'm inclined to think exactly one upstream tarball and one Debian
tarball, each containing .tar.gz's, .diff.gz's and/or .sig's would be
the way to go.
> So, what should a new system look like? Here is a simple proposal,
> without much details:
>
> * Modify the format .dsc file to list the files that contains the sources
> of a package, as well as how to extract that source.
Instructions on how to extract the source. Hmmm. Would "rm -rf /" be a
valid such instruction? What about, say, "rm -rf debian/" if the upstream
tarball includes a debian directory that gets in the way?
One possible thing to consider might be structuring the above tarballs
so that if they're naively unpacked into the current directory you end
up with:
./foo-1.2.3.tar.gz [upstream tarball]
./foo-1.2.3/ [it unpacks into foo-1.2.3]
./foo-1.2.3/debian.diff.gz [debian patch is relative to the
current directory]
./foo-1.2.3/src/addstuff.diff.gz [this is just a patch for foo.c]
This makes it fairly obvious what needs to be for non-Debian people who
want to get at our sources.
OTOH, it doesn't cope with skipping leading directories if they're
not named the way you want them to be, so it can't entirely replace
debian/sources. Equally, some tarballs may need to be moved around after
the fact if the names are too inconvenient. Hmmm. Actually, symlinks
would probably do away with most of the latter problem. Unpacking would
thus consist of something like:
TMP=`tempfile` || exit 1
mkdir unpackdir
cd unpackdir
tar xvf ../foo_1.2.orig.tar
tar xvf ../foo_1.2-1.diff.tar
find -type f > $TMP
cat $TMP | while read line; do (
cd `dirname "$line"` &&
tar xzvf `basename "$line"` &&
rm `basename "$line"`
) done
rm $TMP
OTOH, it might just be too fiddly to setup.
When building, what files should be in ../ ? Supposing I have a couple
of upstream tarballs that I want included, and an upstream patch that
I don't want included, and a couple of random files around. How much
explaining do I have to do to get dh_make or uupdate or debuild to cope?
> * We use a new file, debian/sources, which lists all source files
> and has instructions for unpacking them. For a full description
> of the file see the attached manpage.
This file would have to be duplicated into either the .dsc or in ensuring
the tarballs were laid out appropriately so that dpkg-source -x can get
to it.
> * fiels can be marked as either `upstream' or `debian'. All upstream files
> will be listed in the .dsc file.
Exactly the files that are in the sources/ directory need to be listed in
the .dsc, no more, no less. Unpacking information also has to be available
before unpacking too, which might mean listing everything in the .dsc.
> * When unpacking a package we extract all the tar archives, but don't apply
> any patches. This means we will have the package in its original upstream
> form.
What about upstream patches? What about Debian tarballs?
> * there is a dpkg-patch tool that can apply or reverse patches. It will
> check if patches are applied in order, and can unpack the original source
> and produce a diff from that to the current source so we can easily
> generate a new patch. The status for each patch (applied/not applied)
> will be stores in a debian/status file.
Huh? Why would a patch be distributed if it's not going to be applied?
Why would patches not be applied in order? How can this be checked,
anyway?
> * when building a source package all patches are reversed. Any patches
> that remain are will be the debian-ization patch.
This isn't necessarily possible, is it? Given a.tar, ab.diff, bc.diff
and d/, you can go from a to b to c, and then diff c and d, but you
can't necessarily go from d to b+(d-c) to a+(d-b-c) and diff that against
a and declare that it's the same as cd.diff?
What's wrong with just unpacking the original source, applying the diffs
you've got and then working out the debianization patch in essentially
the same way we do now?
> dir|directory <dir>
> rev|reverse (only for patches)
> fuzz <level> (only for patches)
You probably need a "prune <level>" number of leading `[^/]*/' things to
prune off. Definitely for patches, and ideally for tarballs too, really.
> upstream tar vim-src-5.5.tar.gz
> upstream tar vim-rt-5.5.tar.gz
> upstream patch vim-5.5/debian/patches/5.5.001
> upstream patch vim-5.5/debian/patches/5.5.002
> upstream patch vim-5.5/debian/patches/5.5.003
> upstream patch vim-5.5/debian/patches/5.5.004
> debian patch vim-5.5/debian/patches/deb-pixmapbg
> debian patch vim-5.5/debian/patches/deb-newxterm
For netbase this would presumably look more like:
upstream tar net-tools-1.54.tar.gz dir netbase-3.18/net-tools prune 1
upstream tar ifupdown-0.5.5.tar.gz dir netbase-3.18/ifupdown prune 1
upstream tar ipfwadm-2.3.0.tar.gz dir netbase-3.18/ipfwadm prune 1
upstream tar ipchains-1.3.9.tar.gz dir netbase-3.18/ipchains prune 1
upstream tar ipchains-scripts-1.3.9.tar.gz \
dir netbase-3.18/ipchains-scripts prune 1
upstream tar ipautofw-980511.tar.gz dir netbase-3.18/ipautofw prune 1
upstream tar ipamasqadm-0.4.2.tar.gz dir netbase-3.18/ipautofw prune 1
upstream tar iputils-990107.tar.gz dir netbase-3.18/iputils prune 1
upstream tar netkit-base-0.10.tar.gz \
dir netbase-3.18/netkit-base prune 1
upstream tar portmap-5.tar.gz dir netbase-3.18/portmap prune 1
Without the "prune 1" I'd have to go back to hax0ring the debian/rules to
cope with every version change in every package, which gets irritating.
Really, I'd rather not have to worry about the netbase-3.18 either.
Why are the tarball's in ../, and the patches in debian/patches? Won't
that make the patches get included twice?
If not, doesn't something like:
netbase-3.18/
ifupdown/
ifupdown-0.5.5.tar.gz
...
and a debian/sources with:
upstream tar ifupdown/ifupdown-0.5.5.tar.gz prune 1
seem more convenient and easier to construct? (or
netbase-3.18/ifupdown-0.5.5.tar.gz if you don't do the pruning, and just
cope with the version in the directory instead)
Constructing the Debianization diff would then be done with something
like: (as proof of concept)
TMP=`tempfile` || exit 1
cat debian/sources >$TMP
cp -a . ../debianized
mkdir ../undebianized
cat $TMP | while read updeb type file opts; do
mkdir -p ../undebianized/`dirname $file`
cp $file ../undebianized/$file
done
(
OWD=`/bin/pwd`
cd ../undebianized
dpkg-patch --apply --sources=$OWD/debian/sources
)
cat $TMP | while read updeb type file opts; do
rm -f ../undebianized/$file
rm -f ../debianized/$file
done
diff -urb ../undebianized ../debianized >../debianization.diff
rm -f $TMP
rm -rf ../debianized ../undebianized
mv'ing the tarballs and patches about rather than making a new tree
containing everything but the tarballs would obviously be a nicer
implementation.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgpgkbYB9AvRT.pgp
Description: PGP signature