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

Re: Proposal new source archive format

On Mon, May 01, 2000 at 11:23:08AM -0400, Ben Collins wrote:
> On Mon, May 01, 2000 at 02:56:08PM +0200, Wichert Akkerman wrote:
> > Previously Joey Hess wrote:
> > > Er, you have to list _all_ files, upstream or not. Notice that .diff.gz
> > > is currently listed in .dsc files.
> > 
> > The patch-files are inside the debian diff, which is also listed in the
> > .dsc but is special.
> So we are back to the diff of a diff? Why not make the debian/ a .tar.gz
> for easier change and perusal? If all of the patches are seperate from the
> original source, why do we need to use diff.gz at all for our debian
> stuff?
> it could still be a special .tar.gz. It could even be forced to be named
> pkg-ver-rev-debian.tar.gz (in relation to pkg-ver.orig.tar.gz), and then
> further force the assumption that it contains one directory called
> "debian/" with all of the relevant files/patches in there. Seems like an
> easier plan to me, since you don't need to diff, just tar/untar, and it
> gives the extra added benefit of allowing binary files (gif's, jpeg's
> etc..) to be added by the maintainer (HUGE benefit!).

Well, Wichert raised a few points on IRC and appears to be against this
idea, so I thought I'de refute them here for all to see :)

1) What if the upstream contains a debian/ ?
2) What if upstream wants to include debian/ files similar to a redhat
3) What about Debian native packages?

For #1 there are two possibilities. First we could have a maintainer that
is also part of the upstream authors/developers, in which case the debian/
is likely to be well maintained. For this, there would not need to be a
%.debian.tar.gz file, since it will be kept in the upstream source, and
will most likely be up-to-date.

The second case would be like I have to deal with in shadow. While the
author of shadow updates the debian/ with every release (and is an avid
Debian user), shadow's upstream releases are few and far between. Which
means I have an oudated debian/ to keep up with. I moved to Adam Heath's
first incarnation of this build system for little more reason than to get
away from this upstream directory since it was a pain to modify all those
files. In this case the source-package program would note that I have
%.debian.tar.gz in the .dsc and would unpack the .orig.tar.gz excluding
debian/ so as to avoid conflicts.

This second case to #1 will become more of a problem when we see more
devirgence with Debian based OS's (like Storm, Corel, etc..). The upstream
might decide to include one of their debian/ structures instead of our
own, or they might include ours, but that would make it harder for Storm
or Corel to maintain (or whoever decides to base on Debian).

Issue #2 and #3 are quite simple. The .orig.tar.gz can include a debian/
directory of their own, and then the Debian maintainer can proceed to issue
#1 for how to handle it.

Also note that I am of the belief that it is better to build like this:


...than our current layout of putting debian/ in the same directory as the
original source. Which would make all of the above issues even easier
since using the upstream debian/ will be as simple as running "ln -s
foo-src/debian debian" by the source-package program dependent on whether
a %.debian.tar.gz is included in the .dsc or not.


/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '

Reply to: