"Manuel A. Fernandez Montecelo" writes:
> 2013/7/30 Alberto Luaces <alua...@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.
> Due to the change in osg::Geometry, all these seem to fail compiling. Of
> - 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?
Pkg-osg-devel mailing list