[rawhide] colord pulling in 32bit packages on 64bit installs

Richard Hughes hughsient at gmail.com
Fri Jan 11 08:37:51 UTC 2013


On 10 January 2013 23:55, Kalev Lember <kalevlember at gmail.com> wrote:
> It's 'mash' that decides what gets multilibbed. If I read it right, it
> multilibs packages that install files that match the libdir/*.so.*
> pattern, plus a number of hardcoded special cases. It's a bit like
> magic, we'll see how it turns out in tomorrow's rawhide compose.

Ahh, I see. Less magic, more heuristic :)

> Alright, I've pushed the -libs split to rawhide:
> http://pkgs.fedoraproject.org/cgit/colord.git/commit/?id=30fa2dfe

Great, thanks.

> One thing that's still left to do is to make something require the
> daemon package, so that it gets dragged in for new installs. Can you
> figure out where the dep should go and add it there? (Or possibly leave
> it up to comps to drag it in.)

Well, lots of the desktop requires colord explicitly, so something
should bring it in. Even cups depends on the main package for the
*functionality*, not the library.

> My first reaction was to make colord-libs depend on colord. However,
> since gtk3 (its cups printing backend) is linked against libcolord,
> adding the dep there would make colord daemon and argyllcms a hard dep
> for gtk3; I suppose there might be people with minimal install use cases
> that would prefer a more flexible approach.

I think it's sane to switch the libraries like gtk to dep on
colord-libs, as then just need the library for linking against. It's
perfectly valid to have colord-libs installed and colord (the daemon)
not installed for super-minimal install sets.

Richard


More information about the devel mailing list