stuck

[Jani Monoses]

Hi Martin,

> 
>> There's no transition to worry about for apps that don't care. Those
>> that do can change their deps to the new split-out package, the
>> others can keep depending on the full one and nothing will change
>> for them.
> 
> No, easier. python-gnome2 would then depend on the new
> python-gconf/html/etc., but the XFCE apps would just depend on
> python-gconf.

Right, that's how it's done in the patch. The others keep depending on 
the full one means they get python-gconf via python-gnome2.

> 
>>   - modify the cdbs scripts of a few packages to run two build passes. 
>> Some may need an extra debian/patch but I am working on getting those 
>> upstream so that is optional (i.e. gnome-system-tools)
> 
> I do agree to Seb that maintaining a huge source code patch to
> eliminate Gnome usage is bad. We already do it for two packages and it
> certainly makes upstream updates a pain. IMHO for these cases there
> are little other possiblities than to convince upstream to adopt the
> patch and offer them to help with it (you shouldn't do this all
> yourself, of course, the XFCE upstreams certainly have an interest in
> this as well?)

Right, gnome-system-tools upstream said he'd take the patch, but has not 
yet got around to commit the bits I sent. Evince is still not interested
though, but I am ok with keeping that package separate as in dapper, 
even at the same version as dapper if that helps.

> 
> However, I don't see a reason why we should not multibuild packages if
> they already support this with a configure option.
> 
> cdbs currently does not support multibuild, but that *only* means that
> it is not easier than with plain debhelper (as it should be). But of
> course it is not in any way harder. So let's create a small example
> multibuild package and then see which parts we can generalize into a
> multibuild.mk. Jani, I'd be interested in looking into this.

Gauvain has the gcalctool example I'll let him follow up on this part.

thank you
Jani