#4944: Please mark sane-backends-drivers-{cameras, scanners} multiarch from F-14 on

Fedora Release Engineering rel-eng at fedoraproject.org
Fri Oct 7 12:56:34 UTC 2011


#4944: Please mark sane-backends-drivers-{cameras,scanners} multiarch from F-14 on
-----------------------+----------------------------------------------------
  Reporter:  nphilipp  |       Owner:  rel-eng at lists.fedoraproject.org
      Type:  task      |      Status:  new                            
 Milestone:            |   Component:  mash                           
Resolution:            |    Keywords:                                 
-----------------------+----------------------------------------------------
Comment (by 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?

 > >  * 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.

-- 
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4944#comment:7>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project


More information about the rel-eng mailing list