So, the regex to match against would be something like:

/usr/lib/sane
or possibly tighter, with
/usr/lib/sane/libsane-*
?

I hope it goes without saying (with my rel-eng hat on) this was not a wise change to introduce into older releases...

Doing this on the compose side requires:

1) making a mash patch

2) pushing it as an update for el5/el6

3) waiting for it to make it through the update process

4) pushing it to the compose machines

If this can be done at all in packaging, it's much preferred.

If it's important for us to fix it so 32-bit apps can have drivers with the libraries, why is it important for spins to be able to have libraries without the drivers?

i've several concerns about this update splitting drivers out :

• for < f16, this changes how multilib'ing is done mid-release. problems being though, the spilt package has already gone stable and the damage done. One remedy (at least in the short-term), I'd encourage you to add a hard deps to pre-f16 -libs subpkg:
  {{{
  Requires: %{name}-backends-drivers-cameras%{?_isa} = %{version}-%{release}
  Requires: %{name}-backends-drivers-scanners%{?_isa} = %{version}-%{release}
  }}}

• for f16+ (echo'd from bz): Realize now sane-backends (and apps using it) doesn't "just work", how are these -driver-* subpkgs ever to be installed? are they pulled in via comps somehow or users are now expected to manually install drivers? and, comparing to cups isn't exactly fair, cups includes pk integration to pull in needed drivers on demand... (or is sane-backends able to do something like that?)

Replying to [comment:3 notting]:

If it's important for us to fix it so 32-bit apps can have drivers with the libraries, why is it important for spins to be able to have libraries without the drivers?

This is the reason that was given to me in the first place: "For things like Netbooks, OLPC XOs, and ARM based devices such as tablets this helps reduce the size quite a bit, and now that colord links against sane-backends-libs it ends up pulling in quite a bit of size which in a lot of cases we have < 4GB of space so even 20 meg here and there adds up."

I didn't think of the multiarch angle at that time (obviously) and even if I did I wouldn't have thought it is so complicated to get this in place -- IMO something like that should be done as a change to a configuration file, not source code.

Replying to [comment:4 rdieter]:

i've several concerns about this update splitting drivers out :

• for < f16, this changes how multilib'ing is done mid-release. problems being though, the spilt package has already gone stable and the damage done. One remedy (at least in the short-term), I'd encourage you to add a hard deps to pre-f16 -libs subpkg:
  {{{
  Requires: %{name}-backends-drivers-cameras%{?_isa} = %{version}-%{release}
  Requires: %{name}-backends-drivers-scanners%{?_isa} = %{version}-%{release}
  }}}

If it's all the same, I'd rather add these deps to the -devel subpackage, so the spins in question nave a benefit.

• for f16+ (echo'd from bz): Realize now sane-backends (and apps using it) doesn't "just work", how are these -driver-* subpkgs ever to be installed? are they pulled in via comps somehow or users are now expected to manually install drivers? and, comparing to cups isn't exactly fair, cups includes pk integration to pull in needed drivers on demand... (or is sane-backends able to do something like that?)

They are pulled in via comps, I've added them as default packages for groups which should have scanners working (graphics, design suite).

Replying to [comment:6 nphilipp]:

If it's all the same, I'd rather add these deps to the -devel subpackage, so the spins in question nave a benefit.

I've skimmed through mash code a bit, but while mash.multib knows many multilib methods, mash seems to me to only be able to employ one of them (Mash.config.multilib_method) at a time. So will making the -devel package depend on -drivers-* have the desired effect here?

• for f16+ (echo'd from bz): Realize now sane-backends (and apps using it) doesn't "just work", how are these -driver-* subpkgs ever to be installed? are they pulled in via comps somehow or users are now expected to manually install drivers? and, comparing to cups isn't exactly fair, cups includes pk integration to pull in needed drivers on demand... (or is sane-backends able to do something like that?)

They are pulled in via comps, I've added them as default packages for groups which should have scanners working (graphics, design suite).

Are comps "consumers" (anaconda, PK, e.a.) supposed to cope with packages they don't find in the configured repositories? I'm looking at the case where something would work on an old repository (without -drivers-* packages), but have new comps data. If that is safe, I'd add these packages to old comps.xml as well.

Replying to [comment:7 nphilipp]:

Replying to [comment:6 nphilipp]:

If it's all the same, I'd rather add these deps to the -devel subpackage, so the spins in question nave a benefit.

I've skimmed through mash code a bit, but while mash.multib knows many multilib methods, mash seems to me to only be able to employ one of them (Mash.config.multilib_method) at a time. So will making the -devel package depend on -drivers-* have the desired effect here?

Yes.

They are pulled in via comps, I've added them as default packages for groups which should have scanners working (graphics, design suite).

Are comps "consumers" (anaconda, PK, e.a.) supposed to cope with packages they don't find in the configured repositories? I'm looking at the case where something would work on an old repository (without -drivers-* packages), but have new comps data. If that is safe, I'd add these packages to old comps.xml as well.

groupinstall, etc. will still 'work' if they can't find a package (yum groupinstall will likely print a warning)

How are you handling upgrades - comps isn't used for that.

Replying to [comment:8 notting]:

Replying to [comment:7 nphilipp]:

Replying to [comment:6 nphilipp]:

If it's all the same, I'd rather add these deps to the -devel subpackage, so the spins in question nave a benefit.

I've skimmed through mash code a bit, but while mash.multib knows many multilib methods, mash seems to me to only be able to employ one of them (Mash.config.multilib_method) at a time. So will making the -devel package depend on -drivers-* have the desired effect here?

Yes.

Good, I'll do that then.

They are pulled in via comps, I've added them as default packages for groups which should have scanners working (graphics, design suite).

Are comps "consumers" (anaconda, PK, e.a.) supposed to cope with packages they don't find in the configured repositories? I'm looking at the case where something would work on an old repository (without -drivers-* packages), but have new comps data. If that is safe, I'd add these packages to old comps.xml as well.

groupinstall, etc. will still 'work' if they can't find a package (yum groupinstall will likely print a warning)

How are you handling upgrades - comps isn't used for that.

Old packages are obsoleted by new ones. Basically if you had scanner drivers (subpackage -libs) before, you'll end up with -drivers-scanners being installed, if you had camera drivers (subpackage -libs-gphoto2), -drivers-cameras will be installed. The only way I can think of right now that'd leave you without drivers is if you selected individual packages in e.g. a kickstart installation (i.e. not upgrade), rather than going with groups and their default packages.

I've added the -drivers-* dependencies to the -devel package in Fedora <= 16 and submitted updates, so this ticket should only concern Rawhide/F-17 and greater from now on.

that should fix it, marking resolved.

There's a syntax error in the commit implementing this in mash, here's a patch:

{{{
diff --git a/mash/multilib.py b/mash/multilib.py
index 07258ff..cd4ff01 100644
--- a/mash/multilib.py
+++ b/mash/multilib.py
@@ -161,7 +161,7 @@ class RuntimeMultilibMethod(MultilibMethod):
if dirname in [ '/lib', '/lib64' ] and filename.startswith('libdb-'):
return True
# sane drivers
- if dirname in [ '/usr/lib/sane', '/usr/lib64/sane' ] and filename starts with('libsane-'):
+ if dirname in [ '/usr/lib/sane', '/usr/lib64/sane' ] and filename.startswith('libsane-'):
return True
return False

}}}

Fixed, thanks.