Re: More flexible source format (was Re: gdb is broken?)
[Main body of comments at bottom]
On Wed, Dec 09, 1998 at 01:46:21PM +0100, Roman Hodek wrote:
>
> > I think a lot of people would love to see this. Red Hat already has
> > a multiple-patches source format, which has proven very handy for us
> > (to extract specific fixes).
>
> Yep, I had the RedHat source format somehow in mind. I don't want to
> copy it, but I like the idea of strictly pristine sources plus a set
> of patches. However, I have only vague ideas until now how the new
> format should look like. Here are those ideas:
>
> - Source packages should still consist of three files: the .dsc, an
> .orig.tar.gz, and some file holding all Debian specific stuff. I
> think this should be a tar file, too, but I haven't invented a good
> extension for it yet. (Using .tar.gz again might cause name
> conflicts, and might confuse some tools that scan through the
> source directories manually.)
Hmm, I was thinking of diff.tar.gz, personally. If you don't want to
reuse .tar.gz, diff.tgz? No, too confusing, I think.
> - There should be something to handle .orig.tar.gz files that do not
> unpack into a subdirectory. (So that also such sources can be
> pristine.)
Trivial to add...
> - The Debian tar file contains the debian/ subdir, the set of
> patches, and some metainformation for each patch.
>
> Representing the debian dir as a tar file has the advantage that
> file permissions inside it are preserved automatically, and also
> symlinks and subdirs become possible without any headaches.
I'd really like to see that.
> - The collection of patches needs to be ordered somehow (maybe prefix
> filenames with a 3-digit serial number), so that they can be
> applied in proper order.
No point. I'd rather see a debian/patches file.
> - Meta-information to patches can include:
> + architectures to which they apply (best including a notation for
> excluding some archs)
> + same for operating systems (we already have Hurd besides Linux)
> + a list of additional changes that cannot be represented in a
> diff file: permissions of new files, symlinks
> + maybe some other conditions that restrict applicability of a
> patch (which ones?)
>
> The current dpkg-source can be extended for the new format in a
> backwards-compatible way, i.e. it recognizes the current format can
> still can handle it. This way packages can switch to the new format
> any time they like to.
>
> Furthermore, there should be a tool that builds a new patch based on
> the current unpacked sources and the previously available diff. That
> way it should be easy to modify some files and make an additional
> patch out of these changes. And also nice would be a tool that assists
> maintainers in splitting the current .diff.gz file into separate
> patches.
>
> If some people are interested in further developing these ideas, we
> could either create a mailing list somewhere, or ask Joey if he makes
> a new debian-* list for us. Please don't let us discuss all the
> technical things here on debian-devel, as this list already has enough
> traffic and I usually only have a glance at it.
All sounds good.
I'm Cc:'ing this to debian-dpkg, which is probably the appropriate
place, and to Joey Hess, because of what I would consider a really good
first step: dh_patches. Something along the lines of:
dh_patches --apply patchname1 patchname2 patchname3
dh_patches --remove patchname1 patchname2 patchname3
or even better, just:
dh_patches --remove
and let it work some magic with, say, debian/patches/status.
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| CMU, CS class of 2002 |
| Debian GNU/Linux Developer __ Part-Time Systems Programmer |
| dan@debian.org | | drow@cs.cmu.edu |
\--------------------------------/ \--------------------------------/
Reply to: