Re: Proposal new source archive format
Wichert Akkerman wrote:
> All upstream files should be listed in the .dsc file with a md5sum.
Er, you have to list _all_ files, upstream or not. Notice that .diff.gz
is currently listed in .dsc files. Anything else is not secure, and
would make it impossible to keep track of what parts make up a package
anyway.
> * Modify the format .dsc file to list the files that contains the sources
> of a package, as well as how to extract that source. The sources here are
> all tar archives, either gzip or bzip2 compressed, and the upstream
> patches. For each source there can be a flag that states in what
> directory to unpack a source. This way we can handle sources that don't
> create a subdirectory for themselves, or a source that is shipped in
> multiple archives not all of which must be extracted in the same
> location.
>
> * 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.
I'm confused. First you say the .dsc file contains the file list and
unpack instructions. Then you say debian/sources does. So which? Are the
things a developer lists in debian/sources used to generate the .dsc file
when building the package?
Also, it seems to me you need to go into some detail about how the .dsc
file itself would looks, since it sounds like it would need to look like
some combination of debian/sources and how it looks now.
> * 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.
>
> * 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.
That's nearly as bad a name as the existing debian/files[1]; could you find
something more descriptive?
I don't understand how one is supposed to get from an unpacked and yet
pristine "original upstram form" package to a debianized package. You
use dpkg-patch clearly, but what file does it read? Not debian/sources, it
would seem, since that file by definition wouldn't exist in this
pristine state.
> * when building a binary package we apply all patches. We don't support
> conditional patches since if a patch doesn't work under all conditions
> it is broken anyway.
Why do you delay applying all patches until this state? That seems
rather different than how we do things now, it sounds as if you won't be
working in a fully patched and debianized tree at all, ever, if the
patches are not applied until build time. This would be very difficult
to work in, IMHO (too much like trying to work with rpms). It would also
make life impossible for those of us who check all our debian packages
into CVS.
> * when building a source package all patches are reversed. Any patches
> that remain are will be the debian-ization patch.
Cool idea!
> # Normal upstream sources
> upstream tar vim-src-5.5.tar.gz
> upstream tar vim-rt-5.5.tar.gz
> # Upstream patches
> # 5.5.001: Configure in the top directory did not pass on an
> # argument with a space correctly. For example
> # "./configure --previs="/My home".
> upstream patch vim-5.5/debian/patches/5.5.001
Woah. What's this debian/patches stuff? Where do these patches come
from and how are they stored in the archive and in the .dsc file? I think
some details are missing here.
> # 5.5.002: Compilation error for using "fds[] & POLLIN".
> upstream patch vim-5.5/debian/patches/5.5.002
> # 5.5.003: The autoconf check for sizeof(int) is wrong on
> # machines where sizeof(size_t) != sizeof(int).
> upstream patch vim-5.5/debian/patches/5.5.003
> # 5.5.004: On Unix it's not possible to interrupt ":sleep 100".
> upstream patch vim-5.5/debian/patches/5.5.004
> # pixmapbg: support a pixmap background in the editing window
> debian patch vim-5.5/debian/patches/deb-pixmapbg
> # newxterm: handle features of new xterm
> debian patch vim-5.5/debian/patches/deb-newxterm
Seems like vim is a rather bad example since it has debian/ in upstream.
I assume a more typical package would also have one of these two:
debian tar vim-debian.tar.gz
debian patch vim-debian.diff.gz
--
see shy jo
[1] Which is incidentially, my least favorite part of the current build
process!
Reply to: