[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: