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 11-22-2009, 09:07 AM
Mike Hommey
 
Default New source package formats now available

On Sun, Nov 22, 2009 at 10:48:14AM +0100, Raphael Hertzog wrote:
> Because you want the patch to be clearly identified and to carry its
> meta-information. Or because maybe you're applying 2 separate patches in
> the same NMU upload.

"Fixing cosmetic issues or changing the packaging style in NMUs is
discouraged."

Adding a patching system is surely changing the packaging style.

> > OTOH, "dpkg-source -x" should result in the same tree (including the .pc
> > directory), whatever the status of quilt installation is on the system.
> > Or if that is not possible without quilt, then dpkg-dev should depend on
> > quilt.
>
> I don't agree with that statement. dpkg-source implements a subset of
> quilt to work without that tool installed, that subset defines the
> interface of the source package and it does not include the .pc directory
> in the general case. If you want that part which is internal to quilt
> itself, you just have to install quilt.

My point is : dpkg-source -x should be idempotent, whatever other
packages are installed when you do it. The fact that you can't
dpkg-source -x, and *then* install quilt to manage the patches is a
nuisance.

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-22-2009, 09:30 AM
Raphael Hertzog
 
Default New source package formats now available

On Sun, 22 Nov 2009, Mike Hommey wrote:
> On Sun, Nov 22, 2009 at 10:48:14AM +0100, Raphael Hertzog wrote:
> > Because you want the patch to be clearly identified and to carry its
> > meta-information. Or because maybe you're applying 2 separate patches in
> > the same NMU upload.
>
> "Fixing cosmetic issues or changing the packaging style in NMUs is
> discouraged."
>
> Adding a patching system is surely changing the packaging style.

Exactly, that is why 1.0 is less NMU-friendly than 3.0 (quilt)... you
can't do the right thing in a NMU, either you break the above rule or
you have to meld patches in the .diff.gz with no other information
than what you put in the changelog.

> My point is : dpkg-source -x should be idempotent, whatever other
> packages are installed when you do it. The fact that you can't
> dpkg-source -x, and *then* install quilt to manage the patches is a
> nuisance.

It's a minor one, yes. But it should happen only once... the next time
will be still be installed. And since quilt is not needed during a simple
build, I don't see the need to add it the dependencies of dpkg-dev.

Cheers,
--
Raphal Hertzog


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-22-2009, 10:26 AM
Charles Plessy
 
Default New source package formats now available

Le Sat, Nov 21, 2009 at 08:51:51PM +0100, Raphael Hertzog a écrit :
>
> Currently a package without a patch system needs heavy modifications in
> debian/rules to setup the patch system. So when you want to add a patch in
> debian/patches and not in the .diff.gz, you have to choose a patch system
> in place of the maintainer.

That sounds like an artificial situation to me. Either the maintainer is active
and a patch system can be agreed with him, or the maintainer is MIA and the
package should be hijacked, orphaned, or removed. It is more work than just doing
a NMU, but it fixes the real problem, which is not the bug itself but the absence
of a maintainer to deal with it.

Also, as a side comment, I would like to add that the “NMU*workflow” often
advertised on this list completely ignores that a large number of packages are
stored in a VCS where all DDs have write acceess. Uploading a package with an
anonymous and monolithic patch puts an additional load on the maintainer's work,
which contradicts the goal of a NMU, to help a busy maintainer.

The formats ‘2.0’ and ‘3.0 (variant)’ bring a lot of nice improvements, like
the use of multiple tarballs, different compression systems, and having the
debian directory in a single tarball, which removes the need of uuencoding
binary documents. I would welcome a variant that leaves the patch system in the
hands of the maintainer. It would simplify our work by removing the need to
fight against the modifications introduced by runing the autotools, which would
be simply ignored instead of being turned into an useless patch. And it would
also open a way to unify with the VCS-based formats.

Cheers,

--
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 11-22-2009, 10:43 AM
Raphael Hertzog
 
Default New source package formats now available

On Sun, 22 Nov 2009, Charles Plessy wrote:
> Also, as a side comment, I would like to add that the “NMU*workflow” often
> advertised on this list completely ignores that a large number of packages are
> stored in a VCS where all DDs have write acceess. Uploading a package with an
> anonymous and monolithic patch puts an additional load on the maintainer's work,
> which contradicts the goal of a NMU, to help a busy maintainer.

Well, IMO, the VCS helper tool should have a tool to import an NMU.
git-buildpackage has git-import-dsc for example.

> The formats ‘2.0’ and ‘3.0 (variant)’ bring a lot of nice improvements, like
> the use of multiple tarballs, different compression systems, and having the
> debian directory in a single tarball, which removes the need of uuencoding
> binary documents. I would welcome a variant that leaves the patch system in the
> hands of the maintainer. It would simplify our work by removing the need to
> fight against the modifications introduced by runing the autotools, which would
> be simply ignored instead of being turned into an useless patch. And it would
> also open a way to unify with the VCS-based formats.

You're fighting the wrong target here, your clean rules should bring the
package in a clean state again.

However, we have debian/source/options now to pass default options to
dpkg-source, we can certainly add more options to change the default set
of ignored files (-i command line option currently) so that you don't end
up with a supplementary patch in that case.

Cheers,
--
Raphaël Hertzog


--
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 04:53 PM.

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