[Pkg-osg-devel] [Alberto Luaces] Re: About to upload 3.2.0~rc1

[Alberto Luaces]

"Manuel A. Fernandez Montecelo" writes:

> 2013/7/30 Alberto Luaces <aluaces at udc.es>:
>>> So that's it, I'm building (and if succesfull, upload) this version,
>>> after the long delay.
>>
>> Ooops! I haven't had any time to say that 3.2.0 just had been released
>> last week.  I promise to have it ready this week :)
>
> It built fine and I uploaded it a few hours ago, because I don't know
> if I would be able to devote enough time in the next few days/weeks
> (continuous time to perform all the necessary steps, that is) and
> didn't want to delay it longer.
>

Ok.  My only concern is that lintian said for 3.2.0~rc1 that this name
is a greater version number than 3.2.0, so I don't know if we are going
to have problems later.  I think I remeber we could add a "+" sign un
order to overcome this issue, but I'm not sure.

>
> Now it needs to pass the NEW queue because of the new binary package
> names anyway, which will take a while, and the names will be preserved
> between this RC and the final version.  It has virtually no changes
> with the final 3.2.0 so everything should be fine.
>
> I submitted bug reports for the 6 packages build-depending on openscenegraph.
>

Thanks!

>
>   http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-osg-devel@lists.alioth.debian.org
>
> Due to the change in osg::Geometry, all these seem to fail compiling.  Of these:
>
> - flightgear, simgear and fgrun are part of the same basic package and
> with the same maintainer group, and seem a bit abandoned.
>
> - openwalnut don't know
>
> - choreonoid seems to have an active maintainer and very recent uploads
>
> - osgearth is quite outdated and I read in some list that it has
> license incompatibility problems (openssl and others), so it might as
> well be removed
>
>
> I tried to patch them by replacing osg::Geometry with
> deprecated_osg::Geometry but doesn't seem to work out of the box in
> the cases that I tried (there are additional errors), which are about
> 4 out of the 6.  But some of them are already FTBFS due to other
> problems, like missing -lpthread, and not fixed for months, missing
> from testing in some cases.
>

Oh, sorry!  I already suggested doing so for the openwalnut bug, I need
to rectify that.  Anyway, if it is not working, I will have to tell
upstream that deprecated_osg is not working as it should.

>
> So let's keep an eye on them.
>
> In the future, we might want to get track of this situation with
> library transitions (or provide multiple versions of the library at
> the same time), but since the number of packages are low and not
> widely used, and not very well maintained in some cases (it's likely
> that some of the maintainers will not pay attention to the transition
> anyway), and involves quite a lot of bureaucracy, I didn't think that
> it was necessary in this case -- if we get told off because of this,
> it's my fault.
>

Is it not enough for them to stick with an older version of the library?
As long as someone is using them, they should not be removed from the
archive, am I right?

--
Alberto