#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