[gst-devel] where is library gst.h?

[foser]

On Mon, 2005-07-18 at 14:06 +0200, Thomas Vander Stichele wrote:
> Please point out these inconsistencies so they can be fixed.  Bugs
> shouldn't be disguised as features, but fixed.
> 
> What is the initial example you mention ?

The lack of manpages for the unversioned wrappers of the tools.

> >  and the -broken- tools in
> > gst-plugins.
> 
> What broken tools ? Be more explicit please ?

Last time I checked both gst-visualise & gst-launch-ext were not very
functional, I see there's been some improvement there. Still, depending
on eg. oss being there is not a certainty for success anymore these
days. Both of these tools only come versioned, the implied
inconsistency.

> >  Sure, there are complicated schemes with different
> > versions, sets of packages & order of install that could cause serious
> > headaches on systems,
> 
> I don't see the complication.  It works fine on other platforms.

Yes and RPM hell doesn't exist on Gentoo, the fact that something works
on another distro is no argument in itself of course. Gentoo has a
different approach and some upstream packaging schemes might not fit
that very well, partially because quite a few upstream developers are so
used to their distro's packaging scheme (eg. naming your lib libxml2 is
an RPM-ism).

>   Zaheer
> tells me there's no reason why it would be difficult on Gentoo.

> >  especially with the uncertainty about future
> > directions versioning-wise of gstreamer.
> 
> What uncertainty is there ? If there are questions, ask them.  The
> system was put in place precisely to make it more clear.

I never said that it was impossible, it just wouldn't be very clean and
I think it could be troublesome at times.

> > Mainly I was and am worried about the confusion unversioned binaries
> > might create in a versioned environment. Behaviour is fairly
> > unpredictable to user less knowledgeable. eg. I could imagine people
> > using the unversioned binaries in scripts or tools and suddenly find out
> > that for some unknown reason it all doesn't work anymore, because some
> > pipeline or flag only worked with 0.8 & not with the just installed
> > 1.0 . Trying to dumb-away the fact that gstreamer is versioned is not
> > going to help anyone deal with problems.
> 
> Since we are the people dealing with these problems, it's really
> annoying to have some platform behave differently *just because the
> package maintainer can*.  I'm saying this with my package maintainer hat
> on - I also maintain stuff.  If I disagree with some upstream project, I
> try to resolve it with that project, and I prefer doing it their way,
> not my way - precisely to be more  consistent in behaviour over
> different distros.
> 
> My personal belief is that a package maintainer should have a *very good
> reason* to knowingly work against what the upstream project recommends
> or is asking for packages.

This doesn't even touch the issue I described here: how would be dealt
with situations in which users relied on behaviour changes between
different (minor) versions ? I'm not making a point for our choice, I
question yours.

The point is that behaviour with the same tool (say 'gst-launch') might
be inconsistent over time (already is if I'm not mistaken with some of
the changes 0.8->0.9), that is just bad. The point of versioning things
is that you can rely on behaviour of one version to be consistent within
that version.

This of course hasn't been much of an issue so far, because there was
only one version (0.8) and the just introduced 0.9 only is used by a
select group of developers. I expect however that this will change over
time if you encourage in the docs the usage of unversioned developer
tools (that is why it got introduced), especially when there's even more
versions introduced (say a hypothetical 0.11 branch).

> There's a lot of thinking going on :) FWIW, I haven't seen people
> complain about how things are packaged on Fedora.  Is there really no
> way I can convince you to just please follow our recommendations,
> realizing that it's just nicer to have things be similar across
> systems ? If every package maintainer lets his personal feelings
> overrule the project's wishes, it just means that it works differently
> on every system.  And you still can do what you personally want - just
> don't install that tools package.

This I really don't get. To me it's an issue of not having to explain
users why command X doesn't work when you have gstreamer-0.8, but does
work if you have gstreamer-0.10 installed. If we were to introduce a
gstreamer-tools package with unversioned wrappers, then it would be
mandatory. What would be the point of having an optional tools package
if you still had to tell users they needed to install it? You might as
well tell them to used the versioned binaries, it's both 1 step extra.

> > Versioning got introduced for a good reason, why repeat the mistakes it
> > meant to solve?
> 
> Another vagary.  Are you sure you know the reason why it got introduced,
> what it meant to solve ? Are you sure it's repeating these mistakes you
> might be thinking of ?

It's more meant as a general statement regarding versioning of packages
as a way to have a clear distinction between functionality of different
versions, adding the unversioned binaries really is taking a step
backwards in that sense.

- foser
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20050721/2f494541/attachment.pgp>