[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Some questions on format "3.0 (quilt)" multi-origin

Marco Nenciarini <mnencia@debian.org> writes:

> Rene Engelhard ha scritto:
>> Hi,
>> On Fri, Nov 20, 2009 at 11:28:56AM +0100, Marco Nenciarini wrote:
>>> 3) When a new version of a component is released, how to handle it in  
>>> the new source format? I can't find any standard place where to put meta  
>>> informations regarding extra origin tarball.
>> I don't think there exist one. And as the .tar.gz has to change names
>> anyway because otherwise it'd be the same I think the only option
>> left in this case is something like
>> dovecot_1.2.7.orig-libsieve-0.1.13.tar.gz

Looking at "man dpkg-source" I too don't see anything that would allow
building dovecot 1.2.7-1 with libsieve-0.1.13 and dovecot 1.2.7-2 with
libsieve-0.1.14. So for a libsieve update it looks like you need to
use something like


See below for how ugly that is.
>> Unfortunately that needs a stable update (1.14.27) before you can use this...
>> (because of the -) :( And if you need a libsieve dir then you need to create
>> a symlink.
>> /me has to do the same game for openoffice.org and ooo-build.
> After some thinking I believe this isn't a good idea.
> I think the right way to include a new component or to update one is to
> bump the package source version. Something like:
> dovecot_1.2.7+plugin1.orig-libsieve.tar.gz
> This avoids to let dpkg-source (and the maintainer also) confused when
> you try to build the source, because it uses a completely new namespace.

But then you have




all being duplicates. You might have to duplicate 100MB of source for
a 50k component update.

> Moreover I think that the orig tarball should not be changed without a
> version bump, even if it is composed by multiple files.
> Any comments?
> Regards,
> Marco

Why not split the source into dovecot and libsieve? If they are
released seperately and dovecot can build against multiple versions of
libsieve then that indicates they should be seperated (by/with
upstream) enough to allow building them seperately.


Reply to: