Re: new source package format in dpkg-dev
Le Fri, Mar 28, 2008 at 11:11:07AM +0100, Raphael Hertzog a écrit :
> On Fri, 28 Mar 2008, Raphael Hertzog wrote:
> > My last call for test[1] didn't lead to any feedback at all, which is a pity
> > given the length of the discussion we had about patch management. I'm
> > pretty sure people are interested in the topic... and it's important to
> > make sure that the new code in dpkg-source respond to most of the feature
> > requests that people had.
>
> Ok, some people told me that they have no idea what this is all about and
> they won't install the package to discover it... so here are some other
> elements.
>
> First the updated dpkg-source manual page:
> http://people.debian.org/~hertzog/dpkg-source.html
Hi Raphaël,
first of all, thanks for the on-line documentation.
Before reporting my small test, I would like to quickly summarize my
workflow. I store the debian directory of the packages I make in the
subversion repository of the Debian-Med packaging team, and use
svn-buildpackage with the MergeWithUpstream option to create proper
sources packages, which are then processed through a Sid [p|cow]builder
to get the final packages for upload to Debian. The upstream sources are
usually obtained by `uscan --force-upload', or by hand if it does not
work. The modifications to them are stored as a set of patches in
debian/patches, using quilt as a manager in the majority of the cases.
The patches are usually simple and independant. Our main limitation with
the source format 1.0 is that it can not handle binary files.
I have made a two tests with the glam2 package, that has one patch
modifying two upstream makefiles and that is managed by quilt.
In the first experiment, I inserted a line containing "Format: 2.0" on
top of debian/control in my SVN repository, and ran svn-buildpackage. It
fails because debian/patches/series is not a patch. Format 2.0 could be
useful for us if it would ignore the debian/patches/series file (or
whicherver other name that we could use instead). My gut feeling is that
it would already be useful to developpers if the possibility of
including binary files in the debian directory would be uncoupled from
the patch management, that seems to require much more concerted changes.
In the seconde experiment, I downloaded glam2 using apt-get source in a
temporary directory, added "Format: 3.0 (quilt)" to debian/control and
obtained a source package using dpkg-buildpackage. After removing the
old glam2 package, I unpacked the 3.0 (quilt) source package and tried
to build binary packages with dpkg-buildpackage. It failed with the
following error:
sorbet【glam2-1058】$ LC_ALL=C dpkg-buildpackage
dpkg-buildpackage: set CFLAGS to default value: -g -O2
dpkg-buildpackage: set CPPFLAGS to default value:
dpkg-buildpackage: set LDFLAGS to default value: -Wl,-Bsymbolic-functions
dpkg-buildpackage: set FFLAGS to default value: -g -O2
dpkg-buildpackage: set CXXFLAGS to default value: -g -O2
dpkg-buildpackage: source package glam2
dpkg-buildpackage: source version 1058-1
dpkg-buildpackage: source changed by Charles Plessy <charles-debian-nospam@plessy.org>
dpkg-buildpackage: host architecture powerpc
fakeroot debian/rules clean
test -x debian/rules
test "`id -u`" = 0
# reverse-config must be first
/usr/bin/make -f debian/rules reverse-config
make[1]: Entering directory `/tmp/glam2-1058'
make[1]: Nothing to be done for `reverse-config'.
make[1]: Leaving directory `/tmp/glam2-1058'
if [ -d "." ] ; then \
cd . && QUILT_PATCHES=patches quilt --quiltrc /dev/null pop -a -R || test $? = 2 ; \
fi
Le patch debian-changes-1058-1.diff ne se retire pas proprement (rafraichissez le, ou forcez avec -f)
make: *** [reverse-patches] Error 1
dpkg-buildpackage: failure: fakeroot debian/rules clean gave error exit status 2
I looked at debian/patches/debian-changes-1058-1.diff and it basically reverts
the changes from the debian/patches/Makefile patch (that was alone in format
1.0). I think that I do not feel like adopting this workflow because it adds a
lot of complexity to the source package (how to explain the function of such a
patch?), and because it means that when all quilt patches are on pushed on top,
basically, everything is reverted. However, I use to generate new quilt patches
with all the others already applied.
In conclusion, as long as I use svn-buildpackage's MergeWithUpstream option,
the thing that would motivate me to use a different format than 1.0 is the
possibility to add binary files in the debian directory (we can move them
later). Since the use of quilt is apparently troublesome for developpers doing
QA work, I would consider using a format such as 3.0 (quilt) if it would not
perturbate my workflow too much (i.e. I am OK for a transition, but not for
significant work overhead). Another incetive for using the 2.0 format
is the handling of bzipped upstream tar archives, but again, I think
that it would be more helpful if it were uncoupled from the management
of patches by dpkg.
(CCed to debian-med@l.d.o; more tests, comments and feedback are obviously
welcome).
Have a nice sunday,
--
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan
Reply to: