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

[Alberto Luaces]

Hi Manuel, thanks a lot for your thorough analysis. Answers below:

"Manuel A. Fernandez Montecelo" writes:

> Hi,
>
> On Saturday 02 July 2011 10:49:05 Alberto Luaces wrote:
>> Hello,
>> 
>> the new stable release 3.0.0 came out this week. As I was following the
>> release candidates, no big changes were needed to be done for the final
>> version.
>
> Great work!  I think that having very up to date and high-quality and well-
> maintained packages in every sense is very good for Debian's image in 
> general, and it's mostly you (Alberto) who are taking care of this package 
> alone.
>
> 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 .

>
> Just one thing that I think that you might have oversought: you are
>not
> updating previous lib-SONAMEd versions in Conflict lines.  For example:
> ----------------
> Package: libopenscenegraph80
> Section: libs
> Architecture: any
> Depends: ${misc:Depends}, ${shlibs:Depends}
> Conflicts: libopenscenegraph, libopenscenegraph2, libopenscenegraph3, 
> libopenscenegraph1c2, libopenscenegraph7, libopenscenegraph55
> ----------------
>
> I am not completely sure that this Conflicts thing is necessary or correct, 
> but I think that the intent is to conflict on older versions of the 
> libraries to provide "upgrade path hints" to the resolver.  This Conflicts 
> line migh be necessary to tell the resolver "hey, libwhatever-
> SONAME_previous is myself when I was younger... even if my binary package 
> name changed".
>
> (Sorry for the silly example, but it's difficult to explain for me and I 
> hope that you understand it better this way :) ).
>
> So if all of this is correct, you are missing at least libopenscenegraph65, 
> and I can't remember if we released something between libopenthreads11 and 
> libopenthreads14.
>

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 also feel that
they do have a point, and even I must admit that I have some programs
lying on my hard disk built against older versions that sometimes are a
burden to recompile. Other reasons could be that users should wait for
installing the new OSG version until all packages depending on it would
be rebuilt. As an example, if we did that, all users in Sid — or in nine
days in testing :) — should either uninstall `flightgear' or hold OSG
until it is linked against 3.0.0.

As for the dangling packages problem, it's not easy either to know in an
automated way which libraries should be removed, but at least the user
has `aptitude', which can be used to detect obsolete packages or
`deborphan', which tracks installed dependencies that are no longer
needed. I would say that now we are in a state similar to the kernel
images :) the user has to manually uninstall old versions that are no
longer of any value because we can't foresight system's requirements. I
don't know if this makes sense to you.

>
> Also, to avoid the NMU-related lintian warnings maybe you should add
> yourself to Uploaders even if you are not DM yet, just to avoid the warning.  
> I don't know if there's a standard way to do this, but I think that in most 
> cases non-DDs put themselves as maintainers even if they are not maintainers 
> at all and then get sponsored by a DD, and that's why lintian doesn't 
> complain for those packages.  So adding yourself to Uploaders shouldn't be 
> wrong, or maybe even you should be listed as Maintainer and Loic and me as 
> Uploaders...

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...

Regards, 

Footnotes: 
[1]  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580079

[2]  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580081

-- 
Alberto