Bug 803086 - libosinfo depends on perl
libosinfo depends on perl
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: libosinfo (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
RejectedBlocker
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-13 18:12 EDT by Peter Robinson
Modified: 2012-04-11 23:01 EDT (History)
6 users (show)

See Also:
Fixed In Version: libosinfo-0.1.0-2.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-11 23:01:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Robinson 2012-03-13 18:12:13 EDT
in particular the osinfo-pciids-convert and osinfo-usbids-convert depend on perl. It's not clear exactly what those bits do and whether they are critical.

Unfortunately tracker now depends on libosinfo which means that as totem -> grilo-plugins -> tracker means we now get perl in the live images which adds significant size

So it looks like there's two options, if the above two utils aren't critical (no man pages for them to be able to tell) they should be split out into a -perl or -utils sub package, or the libraries could be moved into a -libs sub package
Comment 1 Daniel Berrange 2012-03-14 04:46:49 EDT
We should probably just remove those two scripts. We added support to read pci.ids and usb.ids natively, so no longer need to convert them to XML first.
Comment 2 Fedora Update System 2012-03-14 07:47:42 EDT
libosinfo-0.1.0-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/libosinfo-0.1.0-2.fc17
Comment 3 Adam Williamson 2012-03-14 17:56:46 EDT
Unless this causes any live image to be bigger than their intended target size, it's not a blocker. Does it?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 4 Peter Robinson 2012-03-14 18:13:13 EDT
(In reply to comment #3)
> Unless this causes any live image to be bigger than their intended target size,
> it's not a blocker. Does it?

pulls perl in so not 100% on sizes, more likely to be nice to have if it doesn't. Sorry I couldn't remember if size was a beta or final blocker
Comment 5 Adam Williamson 2012-03-14 18:38:01 EDT
size blocks beta, but only if the image is actually over target size. desktop image has a *lot* of slack below its target atm (700MB). so do most of the images, currently.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 6 Daniel Berrange 2012-03-15 06:01:54 EDT
I've fixed it regardless, and I've even deleted these obsolete perl scripts in upstream codebase, so they won't reappear in future updates.
Comment 7 Fedora Update System 2012-03-15 22:41:05 EDT
Package libosinfo-0.1.0-2.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libosinfo-0.1.0-2.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-3808/libosinfo-0.1.0-2.fc17
then log in and leave karma (feedback).
Comment 8 Adam Williamson 2012-03-16 14:09:00 EDT
Discussed at 2012-03-16 blocker review meeting. Agreed this is rejected as a blocker as it does not actually appear to cause any currently-generated image to go over its intended size, since they all have a lot of slack, so the criterion "The network installation image, DVD image, and live images for release-blocking desktops must meet current size requirements" is not in fact violated.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 9 Fedora Update System 2012-04-11 23:01:36 EDT
libosinfo-0.1.0-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.