[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: package name changes in atlas-cpp (was Re: library renaming due to changed libstdc++ configuration)

Hi Steve,

On Tuesday 29 November 2005 12:15, Steve Langasek wrote:
> On Tue, Nov 29, 2005 at 11:38:32AM +0100, Stephan Hermann wrote:

> > > I don't see any reason to rename the -dbg packages, generally.
> >
> > For the first cxx transition during Breezy development, I renamed
> > libatlas-cpp-0.5 to libatlas-cpp-0.5c2 because this was our plan. Every
> > package without c102 (from old ABI changes) will get c2 and the other
> > library packages with a c102 suffix, the c102 will be removed.
> >
> > For Debian there was another decision, and it's in the responsibilty of
> > the Debian package maintainer, if he wants to rename or not. (If I recall
> > the mail correctly).
> Absolutely not.  Renaming of library packages on ABI change is mandatory in
> Debian, just as it was for Ubuntu.

Well, yes. But not in the same way as we did in Ubuntu.
Please recall:

[1] http://lists.debian.org/debian-devel/2005/06/msg00315.html

This was the first plan of Matthias, in this post he wrote at least exactly 
this, what we did in Ubuntu.
c102 suffixes will be dropped during rename, and c2 will be added to lib 
packages where no c102 was added during the first transition.

After a while Matthias posted this:

[2] http://lists.debian.org/debian-devel/2005/07/msg00064.html

I'm refering to this paragraph:

There has been a concern about re-renaming library packages
libfoo1c102 back to libfoo1, because this might break third party
packages on systems, that are directly upgraded from potato to etch.
I don't know any of these, but if a package maintainer thinks it's
worth supporting these packages and upgrades, please rename the
package to libfoo1c2. In this case you have to keep the libfooc1
conflict/replace and add the libfoo1c102 conflict/replace.

So actually there was a change in the plan, and during the Dapper Merge Run we 
have right now, we found some packages which are renamed differently from the 
plans discussed in [1].

> Anyway, the fact that there was never a c102 version of libatlas-cpp-0.6 in
> Debian or Ubuntu certainly cuts down on the chances of there being an
> incompatible libatlas-cpp-0.6-0c2 package in the wild.  So it's not
> *crucial* that this package be named -0.6-0c2a, but it would be nice to not
> have gratuitous inter-distro incompatibilities when they can be avoided.

Well, I will try to revert the change, no problem. But even for 
libatlas-cpp-0.6 there was a soname change (if you see this bugreport about 
the rename of libatlas-cpp-0.5) and there was no need to rename 
libatlas-cpp-0.6 because the soname change was introduced by a new upstream 

When I got the merge report into my hands for libatlas-cpp-0.6, there was no 
renaming in rev 1, so I had to add c2a as soname change. I just saw too late, 
that there was a rev 2 of this package, and in this rev a renaming was made.

At the time of the merge, I was right. There is now a difference between 
ubuntu and debian. I'm sorry for that, but I don't change it right now. If 
there is a new upstream of atlas-cpp, we can try to bring the two packages 
again in sync.


Attachment: pgpORhH7a6Tkc.pgp
Description: PGP signature

Reply to: