Re: New source package formats now available
Gerfried Fuchs <rhonda@deb.at> writes:
> Hi! :)
>
> * Raphael Hertzog <hertzog@debian.org> [2009-11-22 10:48:14 CET]:
>> > 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.
>
> Actually, I feel rather to convert my packages to 3.0 (native) + quilt.
> The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to
> me).
>
> If you want to really make proper use of it (like seperating into
> feature patches instead of one per upload) you need to have quilt
> installed anyway, and speaking of NMUs, people that just download the
> source, patch and upload will produce low-standard patches, most
> probably not following the DEP3 because dpkg with 3.0 (quilt) doesn't
> really offer what quilt offers. It feels a bit like the regression that
> svn brought on top of cvs with taking away the posibility to tag
> properly (but create tag-branches instead).
Why do you think that? I can split patches any which way and edit the
debian/patches/series to match all completly without quilt. It only
becomes simpler with quilt and you would always have it installed. A
3.0 (native) + quilt package would force people to use quilt and
result in build failures for anyone missing the fact you use quilt
manually instead of 3.0 (quilt) format. There really is no advantage
in that.
> 3.0 (quilt) looks like a good idea, but it's still rough at the edges
> somehow. :/ And about not needing a README.Source for it, I don't see
> that because otherwise we wouldn't have the need for discussions like
> that, especially if we want to have proper DEP3 tagged patches. :)
Improvements are always welcome.
>> > 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.
>
> It is causing troubles for people that are familiar with quilt and
> think they will be able to work with quilt with the source package when
> they dpkg-source -x it - which unfortunately isn't the case. Only when
> quilt is installed, but then, this is getting different results
> depending on the environment one has, and I thought this was always one
> of the big NO-GOs in Debian that we should avoid - and here we have it
> even intentional? Sorry that this doesn't make me (and from what I can
> see others too) happy :/
And as a quilt using person you often have quilt not installed? Worst
case you unpack the source again after installing quilt. So far this
only happened to me once. Since then I have quilt installed per
default in new chroots ment for compiling.
> About "you just have to install quilt" - *before* you unpack the
> source. If you install it afterwards, you have lost.
So you do want a dpkg-source --quiltify-source to fix this post
unpacking instead of manually unpacking the source again?
Maybe dpkg could note if a package was specifically unpacked without
quilt and otherwise quiltify the source during build when quilt
happens to be available now.
> So long, and thanks. :)
> Rhonda
MfG
Goswin
Reply to: