[Pkg-osg-devel] New upstream stable release 3.0.0

[Manuel A. Fernandez Montecelo]

Hello,

On Thursday 07 July 2011 13:35:24 Alberto Luaces wrote:
> > I already saw that you corrected in the VCS the Standard Version and
> > dpatch issue.  If you want me to upload new revisions please tell me,
> > since I can do it.
> 
> Hmmm... and besides that, it would automatically trigger the
> recompilation on armel, since they updated libqt4 yesterday with the
> changes for not using GLES for the moment. I don't know if we should or
> not, maybe we can wait a few days to see if new things appear. By then I
> could also have solved the remaining informative lintian issues shown in
> http://lintian.debian.org/full/loic@debian.org.html#openscenegraph .

Well, let's take advantage of my power of DM, it's been a while since I 
don't take part in a release of OSG :)

In the case that there are remaining issues we will upload again, or wait 
for 3.0.1 (which maybe they release soon with bugfixes, who knows).

(Note: I tried to upload a new revision but it won't build at the moment, 
the packages depend on libjpeg-dev which is in a transition between 62 and 
8.  I think that the culprit is libgdal-dev and libhdf*.  Trying to set our 
dependency to the old 62 temporarily so we can upload versions doesn't help, 
because some other library does pull 8, and generates the conflicts anyway).

> You have explained yourself pretty clear. The reason why I stopped
> conflicting with previous versions was that I have been warned against
> doing that quite strongly ([1] and [2]) by people that don't want to
> recompile all their stuff as soon as OSG ABI changes.
> [...] I don't know if this makes sense to you.

I didn't recall that, and it makes sense, yep.  If this is a viable 
solution, let's keep it.

IIRC Breaks/Conflicts is mostly for when two packages contain the exactly 
the same files (I can't remember the exact difference between them, nor 
recommended usage, but probably there's documentation explaining it with 
examples).  As long as the .so.SOVERSION is different, they shouldn't 
conflict then.

But in that case, shouldn't be all of the Conflicts be removed?

> Oh, that was it! You really solved the puzzle for me :) I was scratching
> my head because I couldn't understand where that warning came from. I
> think the most correct should be — as the issue appeared because of my
> name being present in a new release — to just acknowledge the NMU in the
> next release, but I would be weird if, for example, I would acknowledge
> my own NMU! Besides that, I wonder if someone besides the Maintainer can
> acknowledge NMUs...

OK, I added you as an Uploader, and kept the changelog entry signed as you.  
Let's see what happens when we can really upload it.

Nevermind about the acknowledgements, nobody really cares about that.  
Your're bodyguarded by Great Loic, who protects you agains furious evils 
lurking in the Debian realm :P

Now, really, no kidding.  I learned this the hard way.  I didn't want to set 
myself as Maintainer/Uploader of a package because I was not a DD not DM, 
but then when I submitted my application, I was not considered very 
seriously among other reasons because I did not appear listed in those 
fields... and people told me that I should have added myself, so...

----

Regarding: "Use --as-needed option of the linker in order to cut unused 
dependencies down", I saw this recently in debian-mentors mailing list:

http://lists.debian.org/debian-mentors/2011/07/msg00193.html

Not that I want to remove what you added, in fact the guy doesn't give any 
explanation and there's no replies to it -- just saying that if the new 
revisions start causing weird "mandelbugs" it might be a good idea to 
remember this.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>