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 05-16-2012, 07:34 AM
Andrey Rahmatullin
 
Default debuild/dpkg-buildpackage behaves not as expected

On Wed, May 16, 2012 at 09:05:21AM +0200, Olе Streicher wrote:
> I just discovered that debuild does not behave as I would expect from
> the maintainer's guide [1]:
>
> | Cleaning the source and rebuilding the package from your user account
> | is as simple as:
> | $ debuild
> [...]
> | You can clean the source tree as simply as:
> | $ debuild clean
>
> This gives an error if the "dh_clean" does not work on the unpatched
> source, since "debuild" reverts all patches, but "debuild clean" does
> not apply then. I filed a bug report for this [2], including a simple
> example package, but the maintainer doesn't see a problem here.
(for the reference) ... because "debuild is just a wrapper around
dpkg-buildpackage" and the behavior "is documented in
dpkg-buildpackage(1)".

--
WBR, wRAR
 
Old 05-16-2012, 08:04 AM
Thibaut Paumard
 
Default debuild/dpkg-buildpackage behaves not as expected

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 16/05/12 09:34, Andrey Rahmatullin a ?crit :
> On Wed, May 16, 2012 at 09:05:21AM +0200, Olе Streicher wrote:
>> I just discovered that debuild does not behave as I would expect
>> from the maintainer's guide [1]:
>>
>> | Cleaning the source and rebuilding the package from your user
>> account | is as simple as: | $ debuild [...] | You can clean the
>> source tree as simply as: | $ debuild clean
>>
>> This gives an error if the "dh_clean" does not work on the
>> unpatched source, since "debuild" reverts all patches, but
>> "debuild clean" does not apply then. I filed a bug report for
>> this [2], including a simple example package, but the maintainer
>> doesn't see a problem here.
> (for the reference) ... because "debuild is just a wrapper around
> dpkg-buildpackage" and the behavior "is documented in
> dpkg-buildpackage(1)".
>

Documented, yes. Rationalized, no. I agree that there's something
fishy with the default behaviour: anytime you have to patch a file
which is later modified during build, you have to build with -tc IIRC.
I agree with Ole that unpatching should never be done before cleaning.

Regards, Thibaut.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+zX6UACgkQ+37NkUuUiPEe5QCfZDjHOHmCeu 6GIKXWTPlXOxkS
TIoAn1sgi+4ufCCc9yTsnYvR3nVDI5gi
=ALCr
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FB35FA5.5070809@users.sourceforge.net">http://lists.debian.org/4FB35FA5.5070809@users.sourceforge.net
 
Old 05-16-2012, 08:53 AM
Norbert Preining
 
Default debuild/dpkg-buildpackage behaves not as expected

On Mi, 16 Mai 2012, Thibaut Paumard wrote:
> fishy with the default behaviour: anytime you have to patch a file
> which is later modified during build, you have to build with -tc IIRC.

Ouch, I had this case (reautoconf vs patching), it lead me to give
up on it. It simply is not worth the pain.

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
WOKING (participial vb.)
Standing in the kitchen wondering what you came in here for.
--- Douglas Adams, The Meaning of Liff


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120516085311.GB25582@gamma.logic.tuwien.ac.at">h ttp://lists.debian.org/20120516085311.GB25582@gamma.logic.tuwien.ac.at
 
Old 05-16-2012, 10:22 AM
James McCoy
 
Default debuild/dpkg-buildpackage behaves not as expected

On Wed, May 16, 2012 at 09:05:21AM +0200, Olе Streicher wrote:
> What is the rationale behind the automatic reversal of the applied
> patches before a cleanup?

Quoting from the bug I meant to refer you to (#649531) when closing the
debuild bug:

On one hand, in dpkg's source format v3, the patched source is considered
to be standard "unpacked" form.

On the other hand, some people like to work most of the time with the
unpatched source, as in pre-v3 days.

"dpkg-source --after-build" distinguishes between the two cases by
checking for the ".pc/.dpkg-source-unapply" file, which is added when
"dpkg-source --before-build" notices that patches were not already
applied. You can ensure patches remain applied by applying the
patches yourself before starting the build.

QUILT_PATCHES=debian/patches quilt push -a
debuild; # or dpkg-buildpackage, or whatever

So, you have a method that you can work with. My main point was that
you should be trying to drive change through dpkg, not through
devscripts.

Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan@debian.org>
 
Old 05-16-2012, 11:23 AM
 
Default debuild/dpkg-buildpackage behaves not as expected

James McCoy <jamessan@debian.org> writes:
> On Wed, May 16, 2012 at 09:05:21AM +0200, Olе Streicher wrote:
>> What is the rationale behind the automatic reversal of the applied
>> patches before a cleanup?
>
> Quoting from the bug I meant to refer you to (#649531) when closing the
> debuild bug:
>
> On one hand, in dpkg's source format v3, the patched source is considered
> to be standard "unpacked" form.
> …
> On the other hand, some people like to work most of the time with the
> unpatched source, as in pre-v3 days.

That sounds that "some people" were favoured over "standard" here.

> My main point was that you should be trying to drive change through
> dpkg, not through devscripts.

I am not sure who is responsible here -- that's why I've put both
commands into the Subject.

Cheers

Ole


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: ytz8vgs8j43.fsf@news.ole.ath.cx">http://lists.debian.org/ytz8vgs8j43.fsf@news.ole.ath.cx
 
Old 05-16-2012, 01:35 PM
Goswin von Brederlow
 
Default debuild/dpkg-buildpackage behaves not as expected

debian-devel@liska.ath.cx (Olе Streicher) writes:

> Hi,
>
> I just discovered that debuild does not behave as I would expect from
> the maintainer's guide [1]:
>
> | Cleaning the source and rebuilding the package from your user account
> | is as simple as:
> | $ debuild
> [...]
> | You can clean the source tree as simply as:
> | $ debuild clean
>
> This gives an error if the "dh_clean" does not work on the unpatched
> source, since "debuild" reverts all patches, but "debuild clean" does
> not apply then. I filed a bug report for this [2], including a simple
> example package, but the maintainer doesn't see a problem here.
>
> For me, the behaviour doesn't look good since the state after "debuild"
> does not make sense to me: all files created during the build process
> (from the patches sources) are still there (including temporary ones),
> but the sources themself do not are not patched anymore. So, build
> results and sources do not fit together after this step. Even more, if
> during the build process one file that has a Debian patch is changed,
> unapplying the patch may fail even if the build change would be reverted
> during the clean process.
>
> What is the rationale behind the automatic reversal of the applied
> patches before a cleanup?

What automatic reversal? There is no automatic reversal. The default
state of source is with patches applied.

% ddsa_0.1-1.dsc
dpkg-source: warning: extracting unsigned source package
(ddsa_0.1-1.dsc)
dpkg-source: info: extracting ddsa in ddsa-0.1
dpkg-source: info: unpacking ddsa_0.1.orig.tar.gz
dpkg-source: info: unpacking ddsa_0.1-1.debian.tar.gz
dpkg-source: info: applying automake
% cd ddsa-0.1/
% debuild
...
dpkg-genchanges: including full source code in upload
dpkg-source --after-build ddsa-0.1
dpkg-buildpackage: full upload (original source is included)
% debuild clean
dh clean --with autoreconf
dh_testdir
dh_auto_clean
make[1]: Entering directory `/data/home/brederlo/src/ddsa/ddsa-0.1'
test -z "" || rm -f
test . = "." || test -z "" || rm -f
rm -f config.status config.cache config.log configure.lineno
config.status.lineno
rm -f Makefile
make[1]: Leaving directory `/data/home/brederlo/src/ddsa/ddsa-0.1'
dh_autoreconf_clean
dh_clean


dpkg-source leaves the source in the same state it finds it before
build. So if you start out with patches applied then they stay
applied. If you manually removed the patches then it is your job to
manually apply them again.

Wether debuild <target> should apply patches before running the target
is arguable. But lets say it does apply patches before the target and
then restores the source to the state it was before after the
target. What happens if you now call

debuild patch

to apply the patches in a 3.0 (quilt) package that has patch/unpatch
targets?

Patches would be applied before that patch target is called, then patch
is called and does nothing (or fails) and then patches are unapplied
again to restore the original state.

Not what you want.


As a solution to your problem I would add patch/unpatch targets to your
source file like this:

QUILT=QUILT_PATCHES=debian/patches quilt --quiltrc /dev/null

PATCH := $(QUILT) push -a || [ "$$($(QUILT) applied)" = "$$(grep -v '^#' debian/patches/series)" ]
UNPATCH := $(QUILT) pop -a || [ "$$($(QUILT) applied 2>&1)" = "No patches applied" ]

patch:
$(PATCH)

unpatch:
$(UNPATCH)

configure-stamp:
$(PATCH)
...

build: build-stamp
build-stamp: configure-stamp
$(PATCH)
...

clean:
$(PATCH)
...
# if you like sources unpatched use unapply-patches in
# debian/source/local-options or:
# $(UNPATCH)

The reason for calling PATCH/UNPATCH directly instead of as dependencies
is so that (un)patch is called again even if it was called before
(because (un)patch might have been called since then) and so that
targets with stamp files don't run every time.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87r4ukp7ts.fsf@frosties.localnet">http://lists.debian.org/87r4ukp7ts.fsf@frosties.localnet
 
Old 05-16-2012, 02:23 PM
 
Default debuild/dpkg-buildpackage behaves not as expected

Goswin von Brederlow <goswin-v-b@web.de> writes:
> What automatic reversal? There is no automatic reversal. The default
> state of source is with patches applied.

Hmm. I have overlooked this when reading bug report #649531.

The order how the steps are applied, is clearly:

1. patch the sources
2. build the package

If you want to reverse this, one clearly should to it in reverse order:

1. cleanup from the build process
2. unpatch the sources

Unpatching the sources *before* the build process was cleaned up makes
no sense to me at all. Could you provide a use case for that?

> Wether debuild <target> should apply patches before running the target
> is arguable. But lets say it does apply patches before the target and
> then restores the source to the state it was before after the
> target. What happens if you now call
>
> debuild patch
>
> to apply the patches in a 3.0 (quilt) package that has patch/unpatch
> targets?
>
> Patches would be applied before that patch target is called, then patch
> is called and does nothing (or fails) and then patches are unapplied
> again to restore the original state.
>
> Not what you want.

A "patch" target would contradict your statement

> dpkg-source leaves the source in the same state it finds it before
> build.

because it does *not* leave the sources in the same state.

Cheers

Ole


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: ytz4nrg8at2.fsf@news.ole.ath.cx">http://lists.debian.org/ytz4nrg8at2.fsf@news.ole.ath.cx
 
Old 05-16-2012, 03:03 PM
Osamu Aoki
 
Default debuild/dpkg-buildpackage behaves not as expected

Hi,

On Wed, May 16, 2012 at 09:05:21AM +0200, Olе Streicher wrote:
> Hi,
>
> I just discovered that debuild does not behave as I would expect from
> the maintainer's guide [1]:

You should say :-)

I just discovered that debuild does not behave as it is described in the
maintainer's guide. So the maintainer's guide can be called buggy but ...

> | Cleaning the source and rebuilding the package from your user account
> | is as simple as:
> | $ debuild
> [...]
> | You can clean the source tree as simply as:
> | $ debuild clean
>
> This gives an error if the "dh_clean" does not work on the unpatched
> source, since "debuild" reverts all patches, but "debuild clean" does
> not apply then. I filed a bug report for this [2], including a simple
> example package, but the maintainer doesn't see a problem here.

Interesting.

> For me, the behaviour doesn't look good since the state after "debuild"
> does not make sense to me: all files created during the build process
> (from the patches sources) are still there (including temporary ones),
> but the sources themself do not are not patched anymore. So, build
> results and sources do not fit together after this step. Even more, if
> during the build process one file that has a Debian patch is changed,
> unapplying the patch may fail even if the build change would be reverted
> during the clean process.
>
> What is the rationale behind the automatic reversal of the applied
> patches before a cleanup?

I do not know. I tends to keep my VCS as patch removed. So I liked
debuild to be this way. I happened not to hit case when debuild clean
is problematic.

(I use debian/source/local-options containing unapply-patches.)

It needs to be resolved at dpkg-buildpackage
http://bugs.debian.org/649531 with everything considered. This is
certainly not debuild problem.

Osamu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120516150354.GA9618@localhost">http://lists.debian.org/20120516150354.GA9618@localhost
 
Old 05-16-2012, 10:25 PM
James McCoy
 
Default debuild/dpkg-buildpackage behaves not as expected

On Wed, May 16, 2012 at 04:23:05PM +0200, Olе Streicher wrote:
> Unpatching the sources *before* the build process was cleaned up makes
> no sense to me at all. Could you provide a use case for that?

As was described in #649531:

vcs clone <repository with unpatched source>
cd repo
... tweak a little ...
dpkg-buildpackage; # applies patches, builds, and unapplies patches
vcs diff; # looks good?
vcs commit

> > dpkg-source leaves the source in the same state it finds it before
> > build.

I think Goswin meant dpkg-buildpackage here.

> because it does *not* leave the sources in the same state.

Yes, it does. If you started with patches applied, then they will still
be applied after calling "dpkg-buildpackage". If you didn't have
patches applied, then "dpkg-buildpackage" will apply the patches, build
and unapply the patches.

--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan@debian.org>
 
Old 05-17-2012, 06:21 AM
Thibaut Paumard
 
Default debuild/dpkg-buildpackage behaves not as expected

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 17/05/12 00:25, James McCoy a écrit :
> On Wed, May 16, 2012 at 04:23:05PM +0200, Olе Streicher wrote:
>> Unpatching the sources *before* the build process was cleaned up
>> makes no sense to me at all. Could you provide a use case for
>> that?
>
> As was described in #649531:
>
> vcs clone <repository with unpatched source> cd repo ... tweak a
> little ... dpkg-buildpackage; # applies patches, builds, and
> unapplies patches

Precisely, the point is that should be:
applies patches, builds, *cleans* and unapplies patches

>> because it does *not* leave the sources in the same state.
>
> Yes, it does.

Nope.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+0mOMACgkQ+37NkUuUiPHvwQCfZ5JgYpy9gM l05G+Crkqui+cx
BG8AnAj2RKjSNZ8DqFVXFXaWP2nJP+hY
=DgDT
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FB498E3.7060906@users.sourceforge.net">http://lists.debian.org/4FB498E3.7060906@users.sourceforge.net
 

Thread Tools




All times are GMT. The time now is 04:39 PM.

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