Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 468400 - getting the SBLIM, openwsman, OMC stacks into Fedora
getting the SBLIM, openwsman, OMC stacks into Fedora
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Bill Nottingham
: Tracking
Depends On: 458024 458025 466183 468287 468329 469002 470293 502596 502818 502834 502843 502854 503482 503495 503496 503510 503727 503939 509445
Blocks: 502609
  Show dependency treegraph
Reported: 2008-10-24 11:47 EDT by Matt Domsch
Modified: 2014-03-16 23:16 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-01-04 17:28:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matt Domsch 2008-10-24 11:47:57 EDT
Description of problem:
http://sblim.wiki.sourceforge.net/ and http://openwsman.org/
includes a boatload of DMTF standards-based open source software for managing systems.

This tracks the inclusion of those components into Fedora.
Comment 1 Matt Domsch 2008-10-27 15:02:11 EDT
Add components from OMC as well.
Comment 2 Jason Tibbitts 2009-07-11 03:27:33 EDT
I just wanted to note that there are many more sblim* review tickets submitted that don't block this ticket, and that none of the review pool seems to have any idea of how to deal with any of them.  I'd wager that none of us has any idea what sblim is.  Is it possible to get any kind of a simple writeup as to what we're supposed to do with all 20+ of these tickets, or perhaps some basic packaging guidelines?
Comment 3 Praveen K Paladugu 2009-07-13 09:58:23 EDT

  The plan is to get these packages into Fedora and in time into "Red Hat" to enable remote management capabilities in "Red Hat".

SBLIM (pronounced "sublime") is an umbrella project for a collection of systems management tools to enable WBEM on Linux. Using the components of the SBLIM project, you can manage your Linux systems using open, standards-based technology.
(From: http://sblim.wiki.sourceforge.net/)

SBLIM (pronounced "sublime"), the Standards Based Linux Instrumentation for Manageability is an IBM-initiated Open Source project, intended to enhance the manageability of GNU/Linux systems. It does so by enabling WBEM, Web Based Enterprise Management.
(From: https://sourceforge.net/projects/sblim/)

I obtained the above primers, please see if this helps.

Thank you
Comment 4 Jason Tibbitts 2009-07-13 11:47:29 EDT
(In reply to comment #3)

>   The plan is to get these packages into Fedora and in time into "Red Hat" to
> enable remote management capabilities in "Red Hat".

Plans for Red Hat are completely immaterial to Fedora.  If someone has a corporate interest in getting these in, perhaps they could also donate some of their corporate manpower or money towards getting them reviewed.  What really matters here is available time and available expertise in the almost entirely volunteer review pool.  

> SBLIM (pronounced "sublime") is an umbrella project for a collection of 
> systems

Yes, that much is clear from wikipedia.

> I obtained the above primers, please see if this helps.

Well, what would really help is something directly related to packaging:

Is there an expected directory structure for the various types of sblim-* packages?  Where do the executable, library and configuration files need to go in order for these packages to be recognized by whatever master daemons control the whole sblim system?  Are there any specific license issues we need to look out for?  Is there a spec file template that these packages can be expected to follow?  Is there a particular format for the package names that needs to be adhered to for server and client components?  That kind of thing.

If you expect to have more of these packages come up in the future, it would be good to take the above and compile it into a guideline document that we can get accepted by the packaging committee so that everyone will be on the same page and we can have quality package submissions, easy reviews and consistent maintainability.
Comment 5 Praveen K Paladugu 2009-09-09 15:01:58 EDT
Some of the rules include:

1) Make sure each provider Requires: tog-pegasus (or sblim-sfcb). Each provider should "Require" anyone cim sever for now. This is going to change in future.

2) Make sure all the cmpi libraries are in /usr/lib/cmpi directory.

3) Make sure all the provider libraries are in /usr/lib directory

3) Each provider should register in %postin and unregister in %preun to the cim server.

4) Some of the providers may have hard-coded shared objects hard coded. So eliminating all the *.so from the base package is not the right thing to do every time. So, check if the names of the shared objects are hard coded in the sources.

5) All the registration and mof files go to /usr/share/%{name}

Above are some of the rules I came across. I will add more, as I come across new ones. 

Sorry for the delay in responding.
Comment 6 Matt Domsch 2009-09-24 12:58:00 EDT

now contains a draft with these rules, somewhat cleaned up.  This needs further review, and to be taken to a Packaging Committee meeting.
Comment 7 Bill Nottingham 2012-01-04 17:28:39 EST
All dependent bugs closed.

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