[Pkg-osg-devel] Project pkg-osg approved in Alioth

[Alberto Luaces]

"Manuel A. Fernandez Montecelo" writes:

[...]

> My proposal is not to do any black magic to hide versions, just name the 
> source package "openscenegraph-2.9" (without the 3rd bit of the version 
> number added, because that's unnecessary) instead of just "openscenegraph", 
> and the binaries in a similar fashion.
>
> Say, now "dpkg -l" says:
>
> ii | openscenegraph | 2.8.3-6 | 3D scene graph, utilities and examples 
> (binaries)
>
> My proposal is that we would have two:
>
> ii | openscenegraph-2.9 | 2.9.1-2 | 3D scene graph, utilities and examples 
> (binaries), development version
>
> ii | openscenegraph-2.10 | 2.10.2-3 | 3D scene graph, utilities and examples 
> (binaries), stable version
>
> Did I explain myself better now? :)
>

Crystal clear, thanks :)

>
>
>> For source compatibility, usually a newer version will do. I have seen
>> for instance that flightgear requires any version newer than 2.8.0, so
>> they won't have to touch their control file regarding OSG version in a
>> long time, unless their upstream required them to do so, or because an
>> OSG non backward-compatible change has arisen.
>
> I think that it was from 1.x to 2.x that the Producer stuff changed, and 
> some changes were needed in other places such as the event system.  So when 
> OSG packages get updated in Debian repos, other packages depending on it 
> (such as flighgear) might break.
>
> Following the example, I was wondering (and that's why I proposed so) if it 
> would be better for flightgear to depend on packages named "osg-2.8" 
> (equivalent to depend on packages with generic name "osg" and versions >= 
> something <= somethingelse).  In this way, we can even have two stable 
> versions (2.8 and 2.10) coexisting for a few weeks or months in the future.  
>

In that case I would go further and use osg1, osg2, osg3... since API
breakings like the one from 1.x to 2.x are not likely to happen so
frequently. osg2 would group, for example, 2.4.x, 2.6.x, 2.8.x... since
they are all source compatible.

>
> But maybe it's not worth the effort, I don't know.  Or it's better to
> maintain the stable package named generically "osg", with no versions 
> contained in the name, for some other reason.
>

Maybe we can do it lazily, only when the problem arises. Imagine that
OSG 3.x is source incompatible with OSG 2.x and upstream's openflight or
others are stuck with the older version for months or years. We can then
craft a special package named osg2 for them to use and for their
packages to be able to hit the testing/stable repositories.

>
>> Now that I'm thinking about it, maybe we could write a rule to get the
>> source from our repository, craft the orig.tar.gz file and continue the
>> build...
>
> We can do this either having the source in our repository, or if not 
> supported, creating the .orig.tar.gz and putting it in Alioth's "files" 
> area.  We only need to do this for every upstream release (every few 
> months), so it's shouldn't be a ton of work.

Ok.

Regards,

Alberto