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
.spec?
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:
foo-1.0/
debian/
foo-src/
...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
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: