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-29-2011, 08:46 AM
Gergely Nagy
 
Default Lintian ERROR saying dpatch is obsolete

Steve Langasek <vorlon@debian.org> writes:

> On Sun, Nov 27, 2011 at 06:44:04PM +0100, Luk Claes wrote:
>> Besides it would be great that everyone uploading has a big reminder to
>> switch away from dpatch. Switching to v3 quilt should be easy.
>
> There are several features of dpatch that can't be trivially migrated to v3
> quilt.
>
> - Custom patch commands, as already discussed. Yes, we should get rid of
> them, but that doesn't make it easy to convert them.

echo skip-patches >>debian/source/options

And then in a pre-build target, do the scripting magic, and call dh $@
--with quilt or something similar, and in clean, do the reverse.

It needs minimal work, but it's - in my opinion - trivial
nevertheless. Less trivial than turning a 00list into series and living
happily ever after, but still trivial.

> - Conditional application of patches. Some packages have patches that are
> only applied on a per-architecture or per-target-distribution basis.

This, indeed, is not trivial to do with 3.0 (quilt). I see this as a 3.0
(quilt) feature, though. But perhaps just my opinion.

> - Patches that don't unapply cleanly after build can be dealt with via
> 'rm -rf' with a custom patch system, but must be made to unapply cleanly
> with v3 (quilt).

This too, is a v3 (quilt) feature, as far as I'm concerned.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 874nxnp8fq.fsf@algernon.balabit">http://lists.debian.org/874nxnp8fq.fsf@algernon.balabit
 
Old 11-29-2011, 09:11 AM
Colin Watson
 
Default Lintian ERROR saying dpatch is obsolete

On Tue, Nov 29, 2011 at 09:56:45AM +0100, Martin Wuertele wrote:
> * Paul Wise <pabs@debian.org> [2011-11-29 03:33]:
> > All of these can be dealt with by rewriting the patch so that it is
> > acceptable to upstream and applied and released by them.
>
> Care to explain how conditional per-target-distribution patches should
> be bushed upstream? Think of patches requried for debian/sid,
> debian/squeeze-backports, ubuntu/Oneric Ocelot and ubuntu/Lucid Lynx
> when it comes to build dependencies.

You can always make the patch conditional on an environment variable or
similar and set that in debian/rules according to the target
distribution. It's a small rewrite, but not that much, and it can often
be less confusing when you're finished.

--
Colin Watson [cjwatson@debian.org]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111129101109.GB19661@riva.dynamic.greenend.org.u k">http://lists.debian.org/20111129101109.GB19661@riva.dynamic.greenend.org.u k
 
Old 11-29-2011, 09:11 AM
Gergely Nagy
 
Default Lintian ERROR saying dpatch is obsolete

Martin Wuertele <maxx@debian.org> writes:

> * Roger Leigh <rleigh@codelibre.net> [2011-11-29 10:04]:
>
> (...)
>> > > > *- Conditional application of patches. *Some packages have patches that are
>> > > > * only applied on a per-architecture or per-target-distribution basis.
>
> (...)
>
>> > > All of these can be dealt with by rewriting the patch so that it is
>> > > acceptable to upstream and applied and released by them.
>> >
>> > Care to explain how conditional per-target-distribution patches should
>> > be bushed upstream? Think of patches requried for debian/sid,
>> > debian/squeeze-backports, ubuntu/Oneric Ocelot and ubuntu/Lucid Lynx
>> > when it comes to build dependencies.
>>
>> Those belong in a version control system, not in a single source
>> package, which is only targetted at a single distribution. Such
>> things can be done very easily on per-distribution branches, e.g.:
>>
>> http://anonscm.debian.org/gitweb/?p=buildd-tools/schroot.git;a=heads
>>
>> Such changes would typically only affect the Debian packaging and
>> not require upstreaming, but even if they did per-distribution
>> branches would still be the way to go.
>
> So the suggested solution is to put the data into an SCM somwhere
> outside the package (LP, git.d.o, $somewhereelse) instead of into the
> package where anyone wanting to deal with the packages is guarantied to
> find it (no downtime, no network required...).

Yes, that's how it should be done, even with dpatch. That you could do
otherwise (and still can, even with quilt, albeit it's thankfully harder
to do it) is unfortunate.

dpatch isn't, and never was meant to support these kind of hacks. It's
not an SCM, never was, never will be, and should not be used as one.

> Doesn't sound like an improvement to me.

It does, because you get proper version control, with branches and all
that stuff. It makes it much clearer what belongs to where, you get
versioning too, and so on and so forth.

A debian package is not meant to be the complete history of itself. It's
a version of a package. That you have different versions for the various
distros, and their versions, is fine, but it should NOT be in the same
source tarball. Use an SCM for that, they were meant to do that, dpatch
wasn't.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87zkffnsq9.fsf@algernon.balabit">http://lists.debian.org/87zkffnsq9.fsf@algernon.balabit
 
Old 11-29-2011, 09:41 AM
Raphael Hertzog
 
Default Lintian ERROR saying dpatch is obsolete

On Tue, 29 Nov 2011, Gergely Nagy wrote:
> > - Custom patch commands, as already discussed. Yes, we should get rid of
> > them, but that doesn't make it easy to convert them.
>
> echo skip-patches >>debian/source/options
>
> And then in a pre-build target, do the scripting magic, and call dh $@
> --with quilt or something similar, and in clean, do the reverse.
>
> It needs minimal work, but it's - in my opinion - trivial
> nevertheless. Less trivial than turning a 00list into series and living
> happily ever after, but still trivial.

Huh no, debian/source/options only affects the build of a source package,
not its unpacking.

And with custom patch commands, people do stuff different from applying
patches in fact... some people mentionned moving or renaming files.

IMO the proper fix in those cases is to integrate all this custom code
directly in debian/rules.

> > - Conditional application of patches. Some packages have patches that are
> > only applied on a per-architecture or per-target-distribution basis.
>
> This, indeed, is not trivial to do with 3.0 (quilt). I see this as a 3.0
> (quilt) feature, though. But perhaps just my opinion.

We do have per-distribution patches series but not per target-distribution
and not per architecture.

It's always possible to apply supplementary patches at build-time but I
agree it's best to create patches that embed whatever conditional is
required (when possible).

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111129104103.GH18263@rivendell.home.ouaza.com">h ttp://lists.debian.org/20111129104103.GH18263@rivendell.home.ouaza.com
 
Old 11-29-2011, 09:46 AM
Roger Leigh
 
Default Lintian ERROR saying dpatch is obsolete

On Tue, Nov 29, 2011 at 10:08:39AM +0100, Martin Wuertele wrote:
> * Roger Leigh <rleigh@codelibre.net> [2011-11-29 10:04]:
>
> (...)
> > > > > *- Conditional application of patches. *Some packages have patches that are
> > > > > * only applied on a per-architecture or per-target-distribution basis.
>
> (...)
>
> > > > All of these can be dealt with by rewriting the patch so that it is
> > > > acceptable to upstream and applied and released by them.
> > >
> > > Care to explain how conditional per-target-distribution patches should
> > > be bushed upstream? Think of patches requried for debian/sid,
> > > debian/squeeze-backports, ubuntu/Oneric Ocelot and ubuntu/Lucid Lynx
> > > when it comes to build dependencies.
> >
> > Those belong in a version control system, not in a single source
> > package, which is only targetted at a single distribution. Such
> > things can be done very easily on per-distribution branches, e.g.:
> >
> > http://anonscm.debian.org/gitweb/?p=buildd-tools/schroot.git;a=heads
> >
> > Such changes would typically only affect the Debian packaging and
> > not require upstreaming, but even if they did per-distribution
> > branches would still be the way to go.
>
> So the suggested solution is to put the data into an SCM somwhere
> outside the package (LP, git.d.o, $somewhereelse) instead of into the
> package where anyone wanting to deal with the packages is guarantied to
> find it (no downtime, no network required...).
> Doesn't sound like an improvement to me.

Everything Gergely said.

There's no need for the version you upload to unstable to have any
support for backports, ubuntu etc. It's a version specific for
unstable. If you want to support multiple versions, do it outside
of the source package. It also makes things much simpler and
clearer.

This is how I prepare a schroot backport:
git checkout squeeze-backport
git merge schroot-1.4 [or specific release tag e.g. debian/schroot-1.4.21-1]
dch ...
git commit debian/changelog

The backport-specific build-dep changes are made on the backport
branch, branched from the schroot-1.4 branch when the backport
was first made. As I make new backports for new stable releases,
the maintenance effort is nothing more than merging the new
release and updating the changelog. The debian packaging needs
no extra complexity to deal with this--it's all taken care of
by the version control. Doing such things directly in the
source package is just wrong.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111129104614.GN17458@codelibre.net">http://lists.debian.org/20111129104614.GN17458@codelibre.net
 
Old 11-29-2011, 10:07 AM
Gergely Nagy
 
Default Lintian ERROR saying dpatch is obsolete

Raphael Hertzog <hertzog@debian.org> writes:

> On Tue, 29 Nov 2011, Gergely Nagy wrote:
>> > - Custom patch commands, as already discussed. Yes, we should get rid of
>> > them, but that doesn't make it easy to convert them.
>>
>> echo skip-patches >>debian/source/options
>>
>> And then in a pre-build target, do the scripting magic, and call dh $@
>> --with quilt or something similar, and in clean, do the reverse.
>>
>> It needs minimal work, but it's - in my opinion - trivial
>> nevertheless. Less trivial than turning a 00list into series and living
>> happily ever after, but still trivial.
>
> Huh no, debian/source/options only affects the build of a source package,
> not its unpacking.

Ah, I see.

> And with custom patch commands, people do stuff different from applying
> patches in fact... some people mentionned moving or renaming files.

Yeah, what I was trying to accomplish is to make dpkg-source -x NOT
apply the quilt patches, so custom commands can be run before they're
applied.

Running stuff aterwards is trivial.

> IMO the proper fix in those cases is to integrate all this custom code
> directly in debian/rules.

Yeah, but at least in one case (hi, apache!) they're using a dpatch
script to do stuff BEFORE they apply patches (as the patches depend on
the results of this script). Converting that to quilt means that the
short dpatch script becomes a huge, useless patch that's pretty much
just noise.

I hoped that skip-patches would help here, but apparently not. That
makes this case a lot harder.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87vcq3nq53.fsf@algernon.balabit">http://lists.debian.org/87vcq3nq53.fsf@algernon.balabit
 
Old 11-29-2011, 04:30 PM
Steve Langasek
 
Default Lintian ERROR saying dpatch is obsolete

On Tue, Nov 29, 2011 at 09:04:31AM +0000, Roger Leigh wrote:
> > > > *- Conditional application of patches. *Some packages have patches that are
> > > > * only applied on a per-architecture or per-target-distribution basis.

> > > All of these can be dealt with by rewriting the patch so that it is
> > > acceptable to upstream and applied and released by them.

> > Care to explain how conditional per-target-distribution patches should
> > be bushed upstream? Think of patches requried for debian/sid,
> > debian/squeeze-backports, ubuntu/Oneric Ocelot and ubuntu/Lucid Lynx
> > when it comes to build dependencies.

> Those belong in a version control system, not in a single source
> package, which is only targetted at a single distribution. Such
> things can be done very easily on per-distribution branches, e.g.:

I agree entirely that this is the correct approach, but *this is beside the
point*, which is that *it's not trivial to convert the affected packages to
use the workflow that we agree is ideal*.

Lecturing people about how they should be doing packaging doesn't change the
facts on the ground.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 11-29-2011, 04:42 PM
Gergely Nagy
 
Default Lintian ERROR saying dpatch is obsolete

Steve Langasek <vorlon@debian.org> writes:

> On Tue, Nov 29, 2011 at 09:04:31AM +0000, Roger Leigh wrote:
>> > > > *- Conditional application of patches. *Some packages have patches that are
>> > > > * only applied on a per-architecture or per-target-distribution basis.
>
>> > > All of these can be dealt with by rewriting the patch so that it is
>> > > acceptable to upstream and applied and released by them.
>
>> > Care to explain how conditional per-target-distribution patches should
>> > be bushed upstream? Think of patches requried for debian/sid,
>> > debian/squeeze-backports, ubuntu/Oneric Ocelot and ubuntu/Lucid Lynx
>> > when it comes to build dependencies.
>
>> Those belong in a version control system, not in a single source
>> package, which is only targetted at a single distribution. Such
>> things can be done very easily on per-distribution branches, e.g.:
>
> I agree entirely that this is the correct approach, but *this is beside the
> point*, which is that *it's not trivial to convert the affected packages to
> use the workflow that we agree is ideal*.
>
> Lecturing people about how they should be doing packaging doesn't change the
> facts on the ground.

Indeed. But I won't think twice if I'm about to break a workflow that
shouldn't have existed in the first place.

In my opinion, this particular case is simple: use a VCS. Done. As far
as I'm concerned, a better, more robust and fare more appropriate tool
exists for the job. Not even one, but half a dozen. I also cannot
imagine how abusing dpatch for this kind of workflow would be superior
to using a VCS, but perhaps my imagination is poor.

So, yeah, it does force a workflow change on whoever is doing this, but
I'd push for that even if it weren't conflicting with my interest to
remove dpatch sometime in the future.

Nevertheless, if and when I encounter packages like this when I start
filing migration bugs, I'll also suggest possible VCS workflows to
support the per-distrib + per-target patches, and I'll happily help
setting these up and hand-holding people until they get comfortable with
it. (Even if that means I have to touch SVN.)

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87mxbeomfr.fsf@algernon.balabit">http://lists.debian.org/87mxbeomfr.fsf@algernon.balabit
 
Old 11-30-2011, 05:12 PM
Goswin von Brederlow
 
Default Lintian ERROR saying dpatch is obsolete

Martin Wuertele <maxx@debian.org> writes:

> * Paul Wise <pabs@debian.org> [2011-11-29 03:33]:
>
>> On Tue, Nov 29, 2011 at 9:04 AM, Steve Langasek wrote:
>>
>> > *- Custom patch commands, as already discussed. *Yes, we should get rid of
>> > * them, but that doesn't make it easy to convert them.
>> >
>> > *- Conditional application of patches. *Some packages have patches that are
>> > * only applied on a per-architecture or per-target-distribution basis.
>> >
>> > *- Patches that don't unapply cleanly after build can be dealt with via
>> > * 'rm -rf' with a custom patch system, but must be made to unapply cleanly
>> > * with v3 (quilt).
>>
>> All of these can be dealt with by rewriting the patch so that it is
>> acceptable to upstream and applied and released by them.
>
> Care to explain how conditional per-target-distribution patches should
> be bushed upstream? Think of patches requried for debian/sid,
> debian/squeeze-backports, ubuntu/Oneric Ocelot and ubuntu/Lucid Lynx
> when it comes to build dependencies.
>
> Thanks,
> Martin

Not talking about sending upstream but about using 3.0 (quilt) for this:

Patches for ubuntu can be put into debian/patches/series.ubuntu. Dpkg
automatically picks the patch series for the vendor it is on.

Maybe vendor support could also be utilized or extended to support
backports and suites.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87pqg9iiob.fsf@frosties.localnet">http://lists.debian.org/87pqg9iiob.fsf@frosties.localnet
 

Thread Tools




All times are GMT. The time now is 12:18 PM.

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