FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 12-28-2009, 11:55 PM
Raphael Geissert
 
Default quilt 3.0 source format and dpkg-source/dpkg-buildpackage

Russ Allbery wrote:
[...]
> For Git-maintained packages like openafs, that would mean
> ignoring all the patch management features and letting it generate a
> single combined Debian diff analogous to the existing 1.0 diff from the
> patched upstream source maintained in Git.
>

I couldn't agree more with you. So far I have not converted any of my
packages, but might consider trying the 3.0 native format which doesn't
seem fool with patch management.

I'm in no way saying that creating quilt format was a waste of time, but we
need to be real an admit it does not fit everyone's needs. I'm glad there's
a native format (although I wonder what's the status of 3.0 git).

Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-29-2009, 01:16 AM
Charles Plessy
 
Default quilt 3.0 source format and dpkg-source/dpkg-buildpackage

Le Mon, Dec 28, 2009 at 12:44:29PM -0500, Joey Hess a écrit :
>
> I would prefer not to see such packages in the archive using source
> format 3.0. We've been down that road with 1.0, and it was not pretty.
> Above all other goals, my goal with putting the framework of source 3.0
> in place was to allow the flexability that that mess never need to
> happen again. Please try to respect that; the benefits of getting this
> consistently right, are widespread, diffuse, but very real.

Dear all,

My vision of pacakaging is the one of somebody who started in 2006. At that
time, my impression was that there was a momentum for moving away the
management of the patching of the upstream sources from dpkg to the package
maintainer. In the context of the format 1.0, I found that move very welcome,
as it allows to break-up a monolithic change into more logical units. Also,
it seems to me that it fits well the ‘Unix philosophy’ of using a combination
of simple tools to perform a complex task.

Consistent with that trend, the three major patch systems used in Debian
unified their interface, in order to let developers apply and deapply patches
with ‘debian/rules (un)patch’ (see http://wiki.debian.org/debian/patches ), and
the Policy now documents this in §*4.9 (not for unpatching). In supplement to
this, README.source points at a more extensive documentation on how to
manage the patches with the different systems.

In parallel, team maintainance of packages in a VCS is also gaining popularity.
In this model, the preparation of an upload is not based on the Debian source
package, but on on the VCS trunk, that may already contain some modifications.
Said differently, the fist step is not ‘dpkg-source -x’, but ‘debcheckout’.
Moreover, some tools like svn-buildpackage offer the possibility to only store
the debian directory of the source package. This leads to a different model of
building where each attempt is made from a clean unpacked original tarball.
Somewhat similarly, the use of git allows to reset the repository very easily
to its original state. In both cases, it looks simpler to me if the patching of
the sources is not done by dpkg itself, but by ‘debian/rules patch’.

Among the remaining problems in 2006, there was the impossibility to ship a
binary file that is not in the original upstream source, the lack of support
for popular formats of upstream archives, such as tar.bz2 and .zip (and
therefore .xpi and .jar), and the impossibility to aggregate multiple upstream
sources in the same Debian source package without creating an artificial
orig.tar.gz.

The source format versions 3.0 (quilt) solves much of the issues in the above
paragraph, but comes with its own patch management system. How about introducing
a new 3.0 variant that has the following features:

- no patch management at unpack time (use debian/rules patch).
- no patch management at pack time (the debian dir is made
in a tar.gz archive, without looking at the upstream directories).

Would such a format have a chance to be accepted some day in our archive?

Have a nice day,

--
Charles Plessy
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-29-2009, 01:36 AM
Paul Wise
 
Default quilt 3.0 source format and dpkg-source/dpkg-buildpackage

On Tue, Dec 29, 2009 at 10:16 AM, Charles Plessy <plessy@debian.org> wrote:

> The source format versions 3.0 (quilt) solves much of the issues in the above
> paragraph, but comes with its own patch management system. How about introducing
> a new 3.0 variant that has the following features:
>
> *- no patch management at unpack time (use debian/rules patch).
> *- no patch management at pack time (the debian dir is made
> * in a tar.gz archive, without looking at the upstream directories).
>
> Would such a format have a chance to be accepted some day in our archive?

It should be easy, just use a directory other than debian/patches to
store your patches.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-29-2009, 05:22 AM
Raphael Geissert
 
Default quilt 3.0 source format and dpkg-source/dpkg-buildpackage

Raphael Geissert wrote:

> Russ Allbery wrote:
> [...]
>> For Git-maintained packages like openafs, that would mean
>> ignoring all the patch management features and letting it generate a
>> single combined Debian diff analogous to the existing 1.0 diff from the
>> patched upstream source maintained in Git.
>>
>
> I couldn't agree more with you. So far I have not converted any of my
> packages, but might consider trying the 3.0 native format which doesn't
> seem fool with patch management.
>

I apparently got fooled by the tricky name of 3.0 _native_, as it refers to
Debian native packages. This is of course not what I'm looking for.

I hope at some point a package format that is friendlier with VCS' is
developed. Until then I'm sticking with 1.0 for all my VCS-managed packages
(I only maintain two packages that fit that criteria).

3.0 would be friendlier if it would only *not* automatically apply the
patches when extracting the source. But then there's not much point for
dpkg to know about patches.

Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-29-2009, 05:40 AM
Russ Allbery
 
Default quilt 3.0 source format and dpkg-source/dpkg-buildpackage

Raphael Geissert <geissert@debian.org> writes:

> 3.0 would be friendlier if it would only *not* automatically apply the
> patches when extracting the source. But then there's not much point for
> dpkg to know about patches.

I do think the problem of not having buildable source after dpkg-source -x
is worth solving, and for a while most everyone was using quilt, so
supporting quilt natively was a solid idea. I've switched over to Git
completely now, though, and while I was a bit dubious when I talked with
people about it two years ago at DebConf, I can see now where patches
aren't the most natural way to think about changes in Git and maintaining
patches is more of a hassle.

I think the way forward for Git-maintained packages is the 3.0 (git)
format, but changed to ship a bundle. That way, relevant branches and
history can be included, and Git is fairly space-efficient so the
additional cost of doing so isn't that bad.

That does have the drawback of being tied to one particular version
control mechanism again, though. I'm wondering if possibly something
using the fast-import format that both bzr and Git support might work,
although I suspect that would lose a lot of the compression benefits.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-29-2009, 07:02 AM
Manoj Srivastava
 
Default quilt 3.0 source format and dpkg-source/dpkg-buildpackage

On Tue, Dec 29 2009, Russ Allbery wrote:

> I think the way forward for Git-maintained packages is the 3.0 (git)
> format, but changed to ship a bundle. That way, relevant branches and
> history can be included, and Git is fairly space-efficient so the
> additional cost of doing so isn't that bad.

As far as I can tell, git-bundle is not submodule friendly. I
would appreciate 3.0 (git) supporting submodules; and I'd be willing to
write code for that (once I am done relocating, that is)

manoj

--
With your bare hands?!?
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-29-2009, 07:10 AM
Mike Hommey
 
Default quilt 3.0 source format and dpkg-source/dpkg-buildpackage

On Mon, Dec 28, 2009 at 10:40:34PM -0800, Russ Allbery wrote:
> Raphael Geissert <geissert@debian.org> writes:
>
> > 3.0 would be friendlier if it would only *not* automatically apply the
> > patches when extracting the source. But then there's not much point for
> > dpkg to know about patches.
>
> I do think the problem of not having buildable source after dpkg-source -x
> is worth solving, and for a while most everyone was using quilt, so
> supporting quilt natively was a solid idea. I've switched over to Git
> completely now, though, and while I was a bit dubious when I talked with
> people about it two years ago at DebConf, I can see now where patches
> aren't the most natural way to think about changes in Git and maintaining
> patches is more of a hassle.
>
> I think the way forward for Git-maintained packages is the 3.0 (git)
> format, but changed to ship a bundle. That way, relevant branches and
> history can be included, and Git is fairly space-efficient so the
> additional cost of doing so isn't that bad.
>
> That does have the drawback of being tied to one particular version
> control mechanism again, though. I'm wondering if possibly something
> using the fast-import format that both bzr and Git support might work,
> although I suspect that would lose a lot of the compression benefits.

How about designing a "patch" format that would handle merges, and a
"series" format that would handle branches ?

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-29-2009, 07:10 AM
Russ Allbery
 
Default quilt 3.0 source format and dpkg-source/dpkg-buildpackage

Manoj Srivastava <srivasta@ieee.org> writes:
> On Tue, Dec 29 2009, Russ Allbery wrote:

>> I think the way forward for Git-maintained packages is the 3.0 (git)
>> format, but changed to ship a bundle. That way, relevant branches and
>> history can be included, and Git is fairly space-efficient so the
>> additional cost of doing so isn't that bad.

> As far as I can tell, git-bundle is not submodule friendly. I
> would appreciate 3.0 (git) supporting submodules; and I'd be willing to
> write code for that (once I am done relocating, that is)

I think a bundle corresponds to a module, roughly, yes? If so, then one
could presumably write some light infrastructure around multiple bundles
to recreate a source tree with submodules.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-29-2009, 07:11 AM
Tollef Fog Heen
 
Default quilt 3.0 source format and dpkg-source/dpkg-buildpackage

]] Joey Hess

| I think you should be using a dedicated source format for your patch
| system, preferably one that preserves the pre-patched source on unpack
| invariant. Either the existing 3.0 (custom), or a new 3.0 subformat.

Note that those won't be accepted into the archive (at least not without
patches to dak). While I'm not an ftp-master, I would be surprised if
they were happy to take patches for a 3.0 (simple-patchsys). Quilt
isn't that complicated to use and should just replace simple-patchsys,
dbs and similar patch systems.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-29-2009, 07:11 AM
Tollef Fog Heen
 
Default quilt 3.0 source format and dpkg-source/dpkg-buildpackage

]] Joey Hess

| I think you should be using a dedicated source format for your patch
| system, preferably one that preserves the pre-patched source on unpack
| invariant. Either the existing 3.0 (custom), or a new 3.0 subformat.

Note that those won't be accepted into the archive (at least not without
patches to dak). While I'm not an ftp-master, I would be surprised if
they were happy to take patches for a 3.0 (simple-patchsys). Quilt
isn't that complicated to use and should just replace simple-patchsys,
dbs and similar patch systems.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 01:31 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org