[gstreamer-bugs] [Bug 588783] [gst-inspect] Add RPM provides output

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=588783

  GStreamer | gstreamer (core) | Ver: git




------- Comment #15 from Sebastian Dröge  2009-07-29 10:25 UTC -------
(In reply to comment #14)
> (In reply to comment #12)
> > This normalised caps thing is broken by design.
> 
> It is. It's also a functional way of doing things.

I could easily design a new codec + some element that handles it, which would
then break your system if you're using normalized caps. What if some day
there's a codec like

"bling/bla, majorversion=[1,100], minorversion=[0, 1000]"

and a decoder only supports major version [3,30] and minor versions [0,400] for
each? You can't remove the fields then and you would have 27*400 caps lines.

> > (If you want this in gst-inspect for RPM, that's fine with me, I won't fight
> > it, but I'm strongly opposed to establishing normalised caps as the
> > recommended/standard way of doing this stuff for packages in general.)
> 
> RPM provides can only do full string matching. How would one implement the
> functionality in an other way that would be acceptable to you?

By not using RPM for the matching but by using something that uses GStreamer
functionality to match the caps.

> (In reply to comment #13)
> > FYI the packagekit apt backend uses GStreamer logic to find the package that
> > provides the requested codec and also works on the package information I've
> > written about above.
> > 
> > Btw, why do you want this in gst-inspect and can't have this as a separate
> > program?
> 
> Because it means that there's less distribution specific code, which is always
> a good thing.

Well, it could be shipped as part of the packagekit RPM backend.

> > I mean, it's only useful for those few systems that actually use RPM.
> 
> RPM is a required part of the LSB. So I'd argue that it would be used for any
> LSB compliant distribution.

Sure that's many distributions but gst-inspect is also used on non Linux
systems and Linux distributions that are not LSB compliant. I don't see why
adding something RPM specific is a good idea here. Adding some generic format
that can be useful for everybody is but I believe we won't find such format as
our requirements are kind of disjoint.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=588783.