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-21-2009, 06:13 PM
Gerfried Fuchs
 
Default New source package formats now available

Hi!

Some few comments.

* Raphael Hertzog <hertzog@debian.org> [2009-11-21 16:54:36 CET]:
> * even if you don't have any upstream patch right now, next time that
> someone must NMU your package, they can cleanly add a patch (with a
> proper DEP-3 header) without having to modify the build system

This is nothing new for the 3.0 (quilt) format, this is a reason for
any patch system format, so this feels a bit like false-advertising,
sorry. Don't get me wrong, I use quilt where I have to touch upstream
sources myself and totally like it, I just don't see the need to use
this as advertising for the 3.0 format because that doesn't buy you much
more in that respect.

> * in the long run it's best to standardize on a single patch system (new
> contributors need to learn a single system, more people can help you,
> etc.) and quilt appears to be that patch system.

That part feels also a bit strange - I don't think it should be the
decision of the dpkg team to force people to use a specific patch
system. Again, I use quilt myself. Though, Debian (and free software in
general) always was about choice. And yes, I know, there's 3.0 (native),
but that wasn't mentioned.

> When you switch to "3.0 (quilt)", there are other changes that you might
> want to do:
> * You can remove everything related to quilt in debian/rules
> (patch/unpatch logic, cleanup of quilt stamp file and its .pc
> directory).

Unfortunately, I can't follow that "can remove". It sounds like it
would work if you keep it in. Unfortunately that's not the case. Please
take a look at the build logs for wesnoth 1:1.7.8-1. The story is easy:

-) The buildd does a debian/rules clean.
-) quilt doesn't find any applied patches (because dpkg doesn't create
the .pc/ directory structure)
-) The buildd then starts with the building.
-) quilt likes to apply the patches and failes because they already
*are* applied but quilt doesn't know about it.

So pretty please, change that "can remove" into a "MUST remove",
otherwise you will stumble into problems.

> === Does a 3.0 (quilt) source package need to build-depend on quilt? ===
>
> If you drop the quilt usage in debian/rules (patch/unpatch logic), then no.

You *HAVE* to drop the quilt usage in debian/rules, otherwise it will
fail.

So long, and thanks for the work involved, but this minor issues should
still be addressed, in one way or the other.

*waves*
Rhonda


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

Hi,

On Sat, 21 Nov 2009, Gerfried Fuchs wrote:
> * Raphael Hertzog <hertzog@debian.org> [2009-11-21 16:54:36 CET]:
> > * even if you don't have any upstream patch right now, next time that
> > someone must NMU your package, they can cleanly add a patch (with a
> > proper DEP-3 header) without having to modify the build system
>
> This is nothing new for the 3.0 (quilt) format, this is a reason for
> any patch system format, so this feels a bit like false-advertising,
> sorry.

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.

With 3.0 (quilt), you don't need to do any such modification... the patch
system is already available even if not used. That's what this point
means.

> > * in the long run it's best to standardize on a single patch system (new
> > contributors need to learn a single system, more people can help you,
> > etc.) and quilt appears to be that patch system.
>
> That part feels also a bit strange - I don't think it should be the
> decision of the dpkg team to force people to use a specific patch
> system.

We're not forcing anyone, we make it easier for people to use that patch
system and we explain why we think it's a wise choice to consider quilt
as the default patch system to use when you don't have any specific reason
to pick one over the other.

> > * You can remove everything related to quilt in debian/rules
> > (patch/unpatch logic, cleanup of quilt stamp file and its .pc
> > directory).
>
> Unfortunately, I can't follow that "can remove". It sounds like it
> would work if you keep it in.

In general it should work, but you're right that we have a problem
here with the buildds running an old version of sbuild (there are still
many buildd in that situation) because they do "dpkg-source -x" outside
of the buildd chroot where quilt is not installed even if you added
quilt in your build-depends.

AFAIK newer sbuild should do "dpkg-source -x" in the chroot where quilt is
installed due to build-depends and the .pc directory is then created
at unpack time.

> -) quilt doesn't find any applied patches (because dpkg doesn't create
> the .pc/ directory structure)

dpkg-source -x uses quilt if it's installed, so if it's here the .pc
structure is created.

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
 
Old 11-21-2009, 08:25 PM
Mike Hommey
 
Default New source package formats now available

On Sat, Nov 21, 2009 at 08:51:51PM +0100, Raphael Hertzog wrote:
> 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.

If there is no patch system when you are NMUing, why would you want to
add one ?

> We're not forcing anyone, we make it easier for people to use that patch
> system and we explain why we think it's a wise choice to consider quilt
> as the default patch system to use when you don't have any specific reason
> to pick one over the other.

Note that the squeeze release goal only talks about 3.0 (quilt), not 3.0
(native), which kind of suggests 3.0 (quilt) is being forced down.
That's maybe not what you are thinking, but it's how it feels.

> In general it should work, but you're right that we have a problem
> here with the buildds running an old version of sbuild (there are still
> many buildd in that situation) because they do "dpkg-source -x" outside
> of the buildd chroot where quilt is not installed even if you added
> quilt in your build-depends.
>
> AFAIK newer sbuild should do "dpkg-source -x" in the chroot where quilt is
> installed due to build-depends and the .pc directory is then created
> at unpack time.

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.

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-21-2009, 08:35 PM
Gerfried Fuchs
 
Default New source package formats now available

* Raphael Hertzog <hertzog@debian.org> [2009-11-21 20:51:51 CET]:
> Hi,
>
> On Sat, 21 Nov 2009, Gerfried Fuchs wrote:
> > * Raphael Hertzog <hertzog@debian.org> [2009-11-21 16:54:36 CET]:
> > > * even if you don't have any upstream patch right now, next time that
> > > someone must NMU your package, they can cleanly add a patch (with a
> > > proper DEP-3 header) without having to modify the build system
> >
> > This is nothing new for the 3.0 (quilt) format, this is a reason for
> > any patch system format, so this feels a bit like false-advertising,
> > sorry.
>
> 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.

Heavy modification? What's so heavy on three entries there?

include /usr/share/quilt/quilt.make

clean:
[...]
unpatch

build-stamp: patch

Sorry, but these additions are next to nowhere "heavy modifications",
that's a bit over overrating, to say the least.

> With 3.0 (quilt), you don't need to do any such modification... the patch
> system is already available even if not used. That's what this point
> means.

The modifications are implied, but it means that the source format is
already this "heavy modification", on a similarly heavy modification
scale. Additionally, if someone wants to sepearte the patches into
feature-patches instead of one-modification-patch-per-upload they will
have to additionally pull in quilt anyway to work on it properly,
without having it implied through the build-depends and being guided in
the right direction through README.Source.

> In general it should work, but you're right that we have a problem
> here with the buildds running an old version of sbuild (there are still
> many buildd in that situation) because they do "dpkg-source -x" outside
> of the buildd chroot where quilt is not installed even if you added
> quilt in your build-depends.
>
> AFAIK newer sbuild should do "dpkg-source -x" in the chroot where quilt is
> installed due to build-depends and the .pc directory is then created
> at unpack time.
>
> > -) quilt doesn't find any applied patches (because dpkg doesn't create
> > the .pc/ directory structure)
>
> dpkg-source -x uses quilt if it's installed, so if it's here the .pc
> structure is created.

Alright, thanks for explaining the issue - so for the time, what do you
suggest? Remove the quilt handling? Actually ignore the error that quilt
gives (like you suggested on IRC)? Or wait until the sbuild fix is
applied everywhere?

Thanks,
Rhonda


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-21-2009, 11:16 PM
Norbert Preining
 
Default New source package formats now available

On Sa, 21 Nov 2009, Gerfried Fuchs wrote:
> Heavy modification? What's so heavy on three entries there?
>
> include /usr/share/quilt/quilt.make
>
> clean:
> [...]
> unpatch
>
> build-stamp: patch

Besides that that snippet is broken? It made me nuts that quilt people
are changing that snippet and breaking many packages, like all of mine.
It should be:

build-stamp: $(QUILT_STAMPFN)
...

and as far as I see:
clean: unpatch


DOn't get me wrong, I am already using quilt, but the interface with
quilt.make should not change (again, hopefully).

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining Associate Professor
JAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp
Vienna University of Technology preining@logic.at
Debian Developer (Debian TeX Task Force) preining@debian.org
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
ABERBEEG (vb.)
Of amateur actors, to adopt a Mexican accent when called upon to play
any variety of foreigner (except Pakistanis - from whom a Welsh accent
is considered sufficient).
--- 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
 
Old 11-22-2009, 02:30 AM
Goswin von Brederlow
 
Default New source package formats now available

Gerfried Fuchs <rhonda@deb.at> writes:

> Hi!
>
> Some few comments.
>
> * Raphael Hertzog <hertzog@debian.org> [2009-11-21 16:54:36 CET]:
>> * even if you don't have any upstream patch right now, next time that
>> someone must NMU your package, they can cleanly add a patch (with a
>> proper DEP-3 header) without having to modify the build system
>
> This is nothing new for the 3.0 (quilt) format, this is a reason for
> any patch system format, so this feels a bit like false-advertising,
> sorry. Don't get me wrong, I use quilt where I have to touch upstream
> sources myself and totally like it, I just don't see the need to use
> this as advertising for the 3.0 format because that doesn't buy you much
> more in that respect.

The BIG difference is that you (as NMUer) can just

apt-get source foo
cd foo*/
dch -i
$EDITOR file
debuild

and a new patch will be created automatically. You work on the source
as if there is no patch system involved and it will do the right
thing. If you do happen to know about quilt and the package already
has patches you can take advantage of quilt features. You can edit
patches or annotate files to find the guilty patch and so on. But if
you don't know or don't like quilt you can also totaly ignore it.

So what you get is a free (as in nothing needs to be in debian/rules
or Build-Depends) patch system that is also free to anyone using the
source. There is no required learning curve.

>> * in the long run it's best to standardize on a single patch system (new
>> contributors need to learn a single system, more people can help you,
>> etc.) and quilt appears to be that patch system.
>
> That part feels also a bit strange - I don't think it should be the
> decision of the dpkg team to force people to use a specific patch
> system. Again, I use quilt myself. Though, Debian (and free software in
> general) always was about choice. And yes, I know, there's 3.0 (native),
> but that wasn't mentioned.

And the choice is still there. As you say yourself there is 3.0
(native) even if it wasn't advertized. Also things like topgit can be
used and the resulting source package can still use 3.0 (quilt)
format. That will allow for the maintainer to use his/her favourite
environment while everybody else still has to option to use the
resulting source package with or even without quilt. Again, no
learning curve to modify the source.

Maybe think of 3.0 (quilt) more as an interchange format of debian
patches.

>> When you switch to "3.0 (quilt)", there are other changes that you might
>> want to do:

addressed in other mails

MfG
Goswin


--
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, 05:12 AM
Steve Langasek
 
Default New source package formats now available

On Sun, Nov 22, 2009 at 01:16:47AM +0100, Norbert Preining wrote:
> Besides that that snippet is broken? It made me nuts that quilt people
> are changing that snippet and breaking many packages, like all of mine.
> It should be:

> build-stamp: $(QUILT_STAMPFN)
> ...

> and as far as I see:
> clean: unpatch

Well, the latter is wrong - this breaks if you're patching the build system.

--
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-22-2009, 06:35 AM
Olivier Berger
 
Default New source package formats now available

Hi.

Le samedi 21 novembre 2009 ŗ 16:54 +0100, Raphael Hertzog a ťcrit :
> Hello,
>

> We have collected some question/answers from early adopters in
> the dedicated wiki page, the most important information is pasted
> below. We hope you will find it helpful to convert your own packages.
> http://wiki.debian.org/Projects/DebSrc3.0#FAQ
>

Maybe that's very explicit for eveyone, but I couldn't find any
explenation for regular humans of what "quilt" is (ok, I think I have a
clue, but remember not all newcomers may be familiar with it for
instance), and then what the difference are between "native" and "quilt"
formats in the page abobe.

As this was a general announcements, maybe recapping these background
facts would have helped.

Sorry if I'm the only one who thinks that this wasn't really obvious for
all concerned parties.

Best regards,
--
Olivier BERGER <olivier.berger@it-sudparis.eu>
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingťnieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


--
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, 08:09 AM
Raphael Hertzog
 
Default New source package formats now available

Hi,

On Sun, 22 Nov 2009, Olivier Berger wrote:
> Maybe that's very explicit for eveyone, but I couldn't find any
> explenation for regular humans of what "quilt" is (ok, I think I have a
> clue, but remember not all newcomers may be familiar with it for
> instance), and then what the difference are between "native" and "quilt"
> formats in the page abobe.

The difference is explained in the dpkg-source manual page, if you feel
like a short introduction would be good on the above page, please write
one, I'll improve it if needed (I'm subscribed to changes on the wiki
page).

Thanks for your help! ;-)

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

Hi,

On Sat, 21 Nov 2009, Mike Hommey wrote:
> On Sat, Nov 21, 2009 at 08:51:51PM +0100, Raphael Hertzog wrote:
> > 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.
>
> If there is no patch system when you are NMUing, why would you want to
> add one ?

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.

> > We're not forcing anyone, we make it easier for people to use that patch
> > system and we explain why we think it's a wise choice to consider quilt
> > as the default patch system to use when you don't have any specific reason
> > to pick one over the other.
>
> Note that the squeeze release goal only talks about 3.0 (quilt), not 3.0
> (native), which kind of suggests 3.0 (quilt) is being forced down.
> That's maybe not what you are thinking, but it's how it feels.

Well, the combination 3.0 (quilt) + 3.0 (native) offers the same range of
choice as 1.0 alone in a more explicit manner. 3.0 (native) is for native
packages and 3.0 (quilt) is for all the other who have an upstream tarball
+ a debian dir.

The release goal is only about 3.0 (quilt) because switching from a native
source package in format 1.0 to 3.0 (native) will always work and thus
requires no preparation work.

> 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.

On Sat, 21 Nov 2009, Gerfried Fuchs wrote:
> > 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.
>
> Heavy modification? What's so heavy on three entries there?

Don't be blocked on the heavy, it will of course depends on how the
package was built (CDBS, debhelper, dh7, hand-crafted). The point is that
you have to choose a patch system in place of the maintainer. You add a
quilt build-depends and associated changes when he uses CDBS and would
have preferred simple-patchsys.

> Sorry, but these additions are next to nowhere "heavy modifications",
> that's a bit over overrating, to say the least.

Agreed, sorry.

> The modifications are implied, but it means that the source format is
> already this "heavy modification", on a similarly heavy modification
> scale. Additionally, if someone wants to sepearte the patches into
> feature-patches instead of one-modification-patch-per-upload they will
> have to additionally pull in quilt anyway to work on it properly,

Well, they can drop the patch in debian/patches, and add it to
the end of debian/patches/series. If quilt is installed, it should
work as dpkg-source will use quilt applied to know
whether patches needs to be applied. If quilt is not installed, it assumes
all patches are applied, so you should also apply the patch.

> Alright, thanks for explaining the issue - so for the time, what do you
> suggest? Remove the quilt handling?

Yes, there's no reason to keep it.

> Actually ignore the error that quilt gives (like you suggested on IRC)?

No, I did not suggest that. I was confused on why you saw the failure and
first thought that it was misusage of quilt.

> Or wait until the sbuild fix is applied everywhere?

No, by experience that would mean to wait for quite long, despite the
efforts of the wanna-build maintainers to get buildd maintainers to update
their buildd.

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 03:37 AM.

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