jani.monoses at gmail.com
Tue Sep 19 10:17:08 BST 2006
>> 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
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.
More information about the ubuntu-devel