please sync libgdamm3.0 (3.0.0-2) from unstable/main to universe

[Chris Brotherton]

Debian now has this package in unstable. Version 3.0.0 is considered a stable release and would be a good addition to hardy.

[Chris Brotherton (protonchris)]

diff.gz for updated package.

Thanks.

[Daniel Holbach (dholbach)]

I guess this needs to go through https://wiki.ubuntu.com/FreezeExceptionProcess

[Chris Brotherton (protonchris)]

Daniel,

I am not sure if this need to be an exception. It can probably wait until Hardy+1. If you want to unsubscribe u-u-s, I can resubscribe them when hardy+1 is ready.

Thanks,
Chris.

[Daniel Holbach (dholbach)]

The upstream changelog certainly looks like it includes a bunch of fixes.

[Chris Brotherton (protonchris)]

Please consider a feature freeze exception for this package. This new version of this software is mostly bugfixes (see changelog above) and does not have significant new features or remove existing features (soname stays the same). Only one package depends on this package, so an upgrade is low risk.

[Luke Yelavich (themuso)]

Firstly, please do not set to confirmed for feature freeze exception bugs. The bug gets set to confirmed when two acks are given to update the package.

As to that, it does appear to be very much a bugfix release, so +1 from me.

[Cesare Tirabassi (norsetto)]

Any impact on glom0 and libglom0?
Note that there is now a package available from sid, so we could just sync.
In this case, we would need to change all rdepends to be compatible with the naming change made by debian though.

[StefanPotyra (sistpoty)]

Hm... if the changelog indicates that the ABI stays the same. However it's worth investigating this:

> * libgda/src/connectionevent.hg: Put the enums inside the Gnome::Gda namespace instead of
> inside Gnome::.

Can you
a) attach a diff of the symbols between the old and the new version (I doubt, there is an unexpected change though, since the changelog seems to be very exact and enums are iirc always mapped to ints). and
b) check, if these enums are part of the public API or just used internally inside libgdamm3.0?

Thanks,
      Stefan.

[Murray Cumming (murrayc)]

> b) check, if these enums are part of the public API or just used internally inside libgdamm3.0?

These enums are part of the public API. (I am the upstream maintainer.)

[StefanPotyra (sistpoty)]

ok, so the public API changed. However since only glom uses it as package so far, and libglom0 doesn't have any rdepends (beside glom), I guess this could be fixed easily, either by modifying the current package or by syncing (rather merging to ensure a sane upgrade) from debian, in case it shouldn't build after an update any longer (also a quick grepping didn't reveal any usage of an enum in the Gnome:: namespace of glom).

Hence, in case a diff of the symbols underlines that the ABI stays the same I'm happy to give an ACK.

[Scott Kitterman (kitterman)]

Ack #2 and approved.

[Chris Brotherton (protonchris)]

glom and libglom0 build and run against the new version of libgdamm3.0 without issue. If there is still interest in a symbols diff, I can provide that tomorrow.

[StefanPotyra (sistpoty)]

well, I guess I don't insist on having a diff of the symbols in this specific case.

[StefanPotyra (sistpoty)]

Thanks for adding that output. Indeed I was surprised: seems like I recalled wrongly, and c++ encodes the namespace of the enum in the symbol (for method signatures). Hence there are removed symbols, and thus the ABI is broken as well.

This means, we cannot sync the package as is. The best solution would be, if you'd make a new upstream release, just bumping the SONAME, and we'd get this one in. The second best solution is to append s.th. to the name of the binary package of the library. (Both of these will have the effect that glom must get rebuilt for the new library).

[Chris Brotherton (protonchris)]

Murray,

What to you think? Are you up for a new release with a soname bump?

Chris.

[StefanPotyra (sistpoty)]

@Murray, above is the promised patch against configure.in, that will bump the SONAME to the next version (it does not set a new upstream version number though).

[Murray Cumming (murrayc)]

Thanks. I have applied that and released libgdamm 2.82.

Note that the *mm libraries don't bother changing the .so version name usually. GTK+ doesn't change it either.

This is because
- It's really hard to get right, because the version string in configure.ac is so disconnected from the eventual version name of the .so file.
- If we specify an ABI break of new API between, for instance, GTK+ 2.11.1 and 2.11.2 (unstable releases) we have no way then to show that there is no API/ABI break (just API additions) between GTK+ 2.10.x and GTK+ 2.12.0 (stable releases).

So you shouldn't really expect us to do this in future. If you think we should (I'm often wrong) then please do try to provide some exact examples of what libraries such as GTK+ should do in particular cases. I've tried to do that for GNOME before and failed.

[Chris Brotherton (protonchris)]

Thanks, Murray.

I'll put an updated package up in the next couple of days.

[Chris Brotherton (protonchris)]

Updated package for version 2.9.82 with soname bump.

[Chris Brotherton (protonchris)]

Please let me know if you guys would like to see anything else.

[Chris Brotherton (protonchris)]

If this new package is accepted, I'll submit a new bug for a glom rebuild.

[Daniel Holbach (dholbach)]

Unsubscribed Ubuntu Sponsors for universe from this bug until motu-release gave another ACK.

[Cesare Tirabassi (norsetto)]

My only concern is the name change they have made in Debian for the binary packages. Since we will eventually sync it could make sense to be prepared already for that, and we could make the transition now.
If however you guys don't think we should bother now and postpone it to intrepid than I'm fine to ack this.

[Scott Kitterman (kitterman)]

Getting a name change done now will make the next LTS-LTS upgrade easier.

[Cesare Tirabassi (norsetto)]

Chris,

to make the transition it is needed to:

1) Change your source package so that it provides binaries named like those in Debian. This is mainly in debian/control and some of the debhelper files (install etc.). You can see this easily by diffing the ubuntu and debian packages.
Note that the difference is just the removal of a dash (-) from the binary names, eg:

Ubuntu: libgdamm-3.0-8
Debian: libgdamm3.0-8

2) Change all libgdamm dependencies of packages in hardy to point to the new naming scheme. You can find these by using apt-cache with the rdepends option:

apt-cache rdepends libgdamm-3.0-8 libgdamm-3.0-dev libgdamm-3.0-doc

libgdamm-3.0-dev
Reverse Depends:
 libglom-dev
 libgdamm-3.0-doc
Reverse Depends:
 libgdamm-3.0-dev
 libgdamm-3.0-8
Reverse Depends:
 libglom0
 libgdamm-3.0-dev
 glom

So this is just the glom src package.

3) Add to your source package transitional packages to ease the gutsy->hardy upgrade. These are dummy packages which just depends on the right dependencies and eventually conflict/replace the old packages.

For example:

Package: libgdamm-3.0-9
Architecture: all
Depends: libgdamm3.0-9
Description: transitional package to new libgdamm naming scheme
 This dummy package is provided to smooth the upgrade to the new libgdamm naming scheme.
 This package can be safely removed.

It is not the case here, but if there was a previous version of the same package one should have added to the libgdamm3.0-9 stanza in debian/control:

Conflicts: libgdamm-3.0-9 (<< ${source:Version})
Replaces: libgdamm-3.0-9 (<< ${source:Version})

4) Request the removal of the old ubuntu packages from the archive

[Chris Brotherton (protonchris)]

Cesare,

Thanks for this info.

Chris.

[Scott Kitterman (kitterman)]

I don't recall and am not in a position to check if this package has any
conffiles or not. If it does, they may need to be moved to a location or
renamed based on the package names. There is a recipe on wiki.debian.org
for how to manage this in preinst/postinst if it's needed.

[Chris Brotherton (protonchris)]

Updated to include binary package rename and transitional packages. I have included the Conflicts and Replaces package fields for the sake of completeness.

[StefanPotyra (sistpoty)]

Hi,

I guess I need to clear up some things here. Let's consider the upgrade path between between ABI incompatible libraries: The user has A installed, which depends on libfoo1. libfoo gets changed in an incompatible way and produces the binary package libfoo2 (in correlation to the SONAME). Having libfoo provide a libfoo1 dummy package, which would conflict/replace on the old libfoo1 package would mean, that the old libfoo1 could get replaced by libfoo1 (dummy) and draw in libfoo2. However, since libfoo2 is not compatible to libfoo1, A would no longer work in this state.

Hence it is essential, that two ABI incompatible library versions can be installed together on the system. (As a result of this, a library package should not have conffiles due to filename conflicts.)

-> Adding conflicts/replaces would not smooth, but rather break the upgrade path. An ABI incompatible library does *not* replace the functionality of the old incompatible version.

Let's see again what would happen if there is no conflicts/replaces:
libfoo1 can not get upgraded, as there is no newer package. a newer A would be upgraded (A will always need to be rebuilt to pick up libfoo2), depending on libfoo2, so this package gets drawn in -> libfoo1 and libfoo2 are both installed. Once no package depends on libfoo1 any longer, libfoo1 is still installed, but no longer needed. A smart package manager will see that libfoo1 was never directly installed, but only drawn in by A and offer the option to remove it (that's what apt-get autoremove can do). Problem solved :).

HTH,
     Stefan.

[Chris Brotherton (protonchris)]

Stefan,

Sorry. I wasn't clear in my comment above. I used the conflicts/replaces fields for the binary package name change and not for the soname change.

For example:

Package: libgdamm3.0-9
Provides: libgdamm-3.0-9
Conflicts: libgdamm-3.0-9 (<< ${source:Version})
Replaces: libgdamm-3.0-9 (<< ${source:Version})

New package name: libgdamm3.0-9
Old package name: libgdamm-3.0-9

Please let me know if I should of done this differently.

Thanks,
Chris.

[StefanPotyra (sistpoty)]

Hi Chris,

Am Samstag 08 März 2008 04:27:50 schrieb Chris Brotherton:
> Stefan,
>
> Sorry. I wasn't clear in my comment above. I used the
> conflicts/replaces fields for the binary package name change and not for
> the soname change.
>
> For example:
>
> Package: libgdamm3.0-9
> Provides: libgdamm-3.0-9
> Conflicts: libgdamm-3.0-9 (<< ${source:Version})
> Replaces: libgdamm-3.0-9 (<< ${source:Version})
>
> New package name: libgdamm3.0-9
> Old package name: libgdamm-3.0-9

Now I'm confused, as I don't see a libgdamm[-]3.0-9 package in either
debian/unstable or ubuntu.

Since debian currently ships the binary libgdamm3.0-8 (probably, to avoid ABI
breakage by using a different binary package name), and ubuntu has
libgdamm-3.0-8 and the new version has a different SONAME, no dummy package
or conflicts/replaces are necessary at all.

Cheers,
     Stefan.

[Cesare Tirabassi (norsetto)]

>Since debian currently ships the binary libgdamm3.0-8 (probably, to avoid ABI
>breakage by using a different binary package name)

No, they just changed the name to have it similar to the old 1.3 branch.
They have not yet packaged the new version (where we have seen the ABI breakage).

>ubuntu has libgdamm-3.0-8 and the new version has a different SONAME, no dummy package
> or conflicts/replaces are necessary at all.

OK, but you still want to remove 3.0-8 don't you, and so for the transition to 3.0-9 you need a dummy package (and yes, you don't need conflicts/replaces). If we want to keep 3.0-8 (but why!?) then yes, I agree.

[StefanPotyra (sistpoty)]

Hi,

Am Samstag 08 März 2008 23:09:40 schrieb Cesare Tirabassi:
> >Since debian currently ships the binary libgdamm3.0-8 (probably, to avoid
> > ABI breakage by using a different binary package name)
>
> No, they just changed the name to have it similar to the old 1.3 branch.
> They have not yet packaged the new version (where we have seen the ABI
> breakage).

Ah, ok.

>
> >ubuntu has libgdamm-3.0-8 and the new version has a different SONAME, no
> > dummy package or conflicts/replaces are necessary at all.
>
> OK, but you still want to remove 3.0-8 don't you,

Yes.

> and so for the
> transition to 3.0-9 you need a dummy package (and yes, you don't need
> conflicts/replaces).

No. Let me try to explain it again: For the upgrade path, you must always
consider what can happen at the *users* system. Hence a package removed from
the archive, means, that it can still be present on a users system during
upgrading.

Now, a dummy package makes sense, if a binary package was renamed, and
provided the same functionality as the old one, because then on the users
system the new binary package will get installed, when upgrading to the dummy
package.

For a library, where the ABI breaks, however it would be fatal to add a
package with conflicts/replaces or a dummy package: On the users system, an
application linked against the old shared object (let's call it libfoo.so.1),
would require to have libfoo.so.1 present, and would not run without it. A
dummy package, to which libfoo1 could get upgraded prior to upgrading the
application linked against it, would of course not contain this very shared
object. Since the SONAME is different in the new libfoo library package,
there would be a libfoo.so.2 (for example) in there, so it also wouldn't make
the application work (rightfully so, because the ABI changed).

I hope this explanation was better than my first try. Please ask, if s.th. is
not yet clear.

Cheers,
    Stefan.

[Cesare Tirabassi (norsetto)]

I think I'm with you. Let me try to write what I understand. On a user system there is foo (in package foo-1), which links to libfoo.so.1 (in package libfoo1-1).
Now we have a new libfoo with a different soname, and so we have libfoo.so.2 in package libfoo2-1 and foo in package foo-2 which links against libfoo.so.2
If the user upgrade foo-1 to foo-2, obviously it will also upgrade to libfoo.so.2 since libfoo2-1 will be a depends of foo-2, so, everything is fine, no dummy is needed (well, libfoo1-1 will still be on that system but in a more complex case I can understand why you would want that).
If the user installs libfoo2-1 then foo will still be ok since that will not remove libfoo1-1.

Wish somebody could write this stuff on a wiki page somewhere....

[Cesare Tirabassi (norsetto)]

Which, in practice for Chris, means there is no need to have a dummy package nor a replaces/conflicts dependency, only the package name change will do, glom will have to be built/depends against the new library and then we can ask archive to remove the old libgdamm, right? Thanks for the explanation Stefan.

[StefanPotyra (sistpoty)]

Cesare, exactly :).

And removing the old binary is a standard task of archive admins, which I assume it will be done once the new binary package gets processed in binary new, so we wouldn't even need to request this.

[Chris Brotherton (protonchris)]

Updated package.

Changelog:
libgdamm3.0 (2.9.82-0ubuntu1) hardy; urgency=low

  * New upstream release. (LP #190744)
  * Updated Standards-Version to 3.7.3
  * Added get-orig-source target to debian/rules.
  * Updated soname
  * Renamed binary packages from libgdamm-3.0-* to libgdamm3.0-*

 -- Christopher Brotherton <email address hidden> Sun, 09 Mar 2008 09:12:20 -0600

[Chris Brotherton (protonchris)]

With all of the above changes, I assume that I need two more ACKs to be approved. If not, let me know and I will subscribe u-u-s.

[StefanPotyra (sistpoty)]

Sure, I'm still ok with the FFe. ACK.

[Scott Kitterman (kitterman)]

Ack #2 again just to avoid potential confusion.

[Xiyue Deng (manphiz)]

Hi, I'm one of the Debian maintainers of libgdamm3.0, and I'd like to sync with ubuntu work. I guess I'll add the proper Conflicts/Replaces for ubuntu to make it easier. According to Murray the stable version of libgdamm3.0 will probably be released in several weeks, so I wish the full sync will happen by then.

[Xiyue Deng (manphiz)]

Murray Cummings has just release libgdamm3.0 stable release 3.0.0, which bumps soversion to 10, and retain the '-' in shared library name. So I guess there'll be no needs to change package name for ubuntu. I'll try to refine the Debian package and upload in a few days (since I need sponsoring before I'm accepted as DM).

[Chris Brotherton (protonchris)]

That is great to hear. I am the one who worked on the most recent package version in ubuntu. Let me know if there is anything I can help with.

[Murray Cumming (murrayc)]

> Murray Cumming has just released libgdamm3.0 stable release 3.0.0, which bumps soversion to 10, and retains the '-' in shared library name.

By the way. I have never heard of any problem with the shared library name, or understood why Debian/Ubuntu might want to rename their packages to add or remove a -. In general, if there is ever something that you would like me to fix upstream, please file a bug.

[Xiyue Deng (manphiz)]

IIRC, Debian changed the naming to match 2.9.81, while upstream changed to match Ubuntu naming in 2.9.82. I'd say the current naming (with '-') is reasonable. Ubuntu has a larger user base than Debian, as glom has entered Ubuntu for some time. It's reasonable to match the Ubuntu naming, and it's not quite a big deal to change the naming in Debian, as it's technically doable and very few people are already using it. So please don't worry, Murray :)

[Chris Brotherton (protonchris)]

Actually, you have it backwards. Initially, ubuntu used the libgdamm-3.0-* naming scheme, but we changed it to match debians (libgdamm3.0-*). So you should not have to change the binary package names in debian.

Murray,
You don't need to worry about the package names (other than the sonames). Ubuntu just changed the binary package names to match debian. So, in the future, ubuntu can just sync from debian.

[Xiyue Deng (manphiz)]

Chris Brotherton <email address hidden> writes:

> Actually, you have it backwards. Initially, ubuntu used the
> libgdamm-3.0-* naming scheme, but we changed it to match debians
> (libgdamm3.0-*). So you should not have to change the binary package
> names in debian.
>

Has this already happened? By searching on
http://packages.ubuntu.com/ I haven't found any package named
libgdamm3.0-*, so I guess it's not released yet. Will it be possible
for Ubuntu to remain its naming convention? I've already changed it
in Debian GNOME SVN to add '-'. Please let me know what you plan to
do, and which Conflicts/Replaces field should be added for Ubuntu.

> Murray,
> You don't need to worry about the package names (other than the sonames). Ubuntu just changed the binary package names to match debian. So, in the future, ubuntu can just sync from debian.
>
> --
> Request: Upgrade libgdamm3.0 to upstream version 2.9.81
> https://bugs.launchpad.net/bugs/190744
> You received this bug notification because you are a direct subscriber
> of the bug.

[Chris Brotherton (protonchris)]

Take a look here: http://packages.ubuntu.com/source/hardy/libgdamm3.0

The new package names are in hardy (scheduled to be released on April 24th).

[Xiyue Deng (manphiz)]

Chris Brotherton <email address hidden> writes:

> Take a look here: http://packages.ubuntu.com/source/hardy/libgdamm3.0
>
> The new package names are in hardy (scheduled to be released on April
> 24th).
>

Thanks for the info. I've changed accordingly in SVN. You can check it
here:

http://svn.debian.org/wsvn/pkg-gnome/packages/unstable/libgdamm3.0/debian/

[Daniel Holbach (dholbach)]

daniel@bert:~$ LC_ALL=C sudo apt-get install -f
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer required:
  libgdamm-3.0-dev libgdamm-3.0-8
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  libgdamm3.0-dev
Suggested packages:
  libgdamm-3.0-doc
The following NEW packages will be installed:
  libgdamm3.0-dev
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
4 not fully installed or removed.
Need to get 0B/91.8kB of archives.
After this operation, 1040kB of additional disk space will be used.
Do you want to continue [Y/n]?
(Reading database ... 163824 files and directories currently installed.)
Unpacking libgdamm3.0-dev (from .../libgdamm3.0-dev_2.9.82-0ubuntu1_amd64.deb) ...
dpkg: error processing /var/cache/apt/archives/libgdamm3.0-dev_2.9.82-0ubuntu1_amd64.deb (--unpack):
 trying to overwrite `/usr/include/libgdamm-3.0/libgdamm/private/blob_p.h', which is also in package libgdamm-3.0-dev
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/libgdamm3.0-dev_2.9.82-0ubuntu1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
daniel@bert:~$

[Daniel Holbach (dholbach)]

Putting sponsoring of bug 202874 on hold until this is fixed.

[Xiyue Deng (manphiz)]

Daniel Holbach <email address hidden> writes:

> daniel@bert:~$ LC_ALL=C sudo apt-get install -f
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Correcting dependencies... Done
> The following packages were automatically installed and are no longer required:
> libgdamm-3.0-dev libgdamm-3.0-8
> Use 'apt-get autoremove' to remove them.
> The following extra packages will be installed:
> libgdamm3.0-dev
> Suggested packages:
> libgdamm-3.0-doc
> The following NEW packages will be installed:
> libgdamm3.0-dev
> 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
> 4 not fully installed or removed.
> Need to get 0B/91.8kB of archives.
> After this operation, 1040kB of additional disk space will be used.
> Do you want to continue [Y/n]?
> (Reading database ... 163824 files and directories currently installed.)
> Unpacking libgdamm3.0-dev (from .../libgdamm3.0-dev_2.9.82-0ubuntu1_amd64.deb) ...
> dpkg: error processing /var/cache/apt/archives/libgdamm3.0-dev_2.9.82-0ubuntu1_amd64.deb (--unpack):
> trying to overwrite
> `/usr/include/libgdamm-3.0/libgdamm/private/blob_p.h', which is also
> in package libgdamm-3.0-dev

This is caused by not having proper Conflicts/Replaces field for
libgdamm3.0-dev in debian/control. I've done this in Debian. Should
be fixed when my package is uploaded and Ubuntu syncs.

> dpkg-deb: subprocess paste killed by signal (Broken pipe)
> Errors were encountered while processing:
> /var/cache/apt/archives/libgdamm3.0-dev_2.9.82-0ubuntu1_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> daniel@bert:~$
>
>
> ** Changed in: libgdamm3.0 (Ubuntu)
> Importance: Undecided => High
> Status: Fix Released => Confirmed
>
> --
> Request: Upgrade libgdamm3.0 to upstream version 2.9.81
> https://bugs.launchpad.net/bugs/190744
> You received this bug notification because you are a direct subscriber
> of the bug.

[Daniel Holbach (dholbach)]

We should merge the change ASAP.

[Xiyue Deng (manphiz)]

Daniel Holbach <email address hidden> writes:

> We should merge the change ASAP.
>

Now it's sitting on Debian NEW queue.

[Chris Brotherton (protonchris)]

I should be able to address this issue this evening after work.

[Chris Brotherton (protonchris)]

I suggest that we stick with our 2.9.82 version of libgdamm3.0 and then sync after hardy is released to the 3.0.0 version in debian. The debian version has a number of changes and includes a soname change.

To address the above problems, I included conflicts/replaces fields for the libgdamm3.0-dev and libgdamm3.0-docs binary packages. I also included transitional packages for the -dev and -doc binary packages. Please let me know if this is appropriate, my control file is below. For the conflicts/replace fields, I used the previous version of the libgdamm3.0 package since it was the first version to include the name change.

---------------------------------------
Control File

Source: libgdamm3.0
Section: devel
Priority: extra
Maintainer: Ubuntu Desktop Team <email address hidden>
Build-Depends: cdbs, debhelper (>= 5), autotools-dev, libglibmm-2.4-dev (>= 2.12.8), libgda3-dev (>= 3.0.0)
Standards-Version: 3.7.3

Package: libgdamm3.0-9
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: C++ wrappers for libgda
 libgdamm is a set of C++ bindings for the libgda database API.
 .
 This package contains the library.

Package: libgdamm3.0-dev
Provides: libgdamm-3.0-dev
Conflicts: libgdamm-3.0-dev (<< 2.9.82-0ubuntu1)
Replaces: libgdamm-3.0-dev (<< 2.9.82-0ubuntu1)
Architecture: any
Section: libdevel
Depends: ${misc:Depends}, libgdamm3.0-9 (= ${binary:Version}), libglibmm-2.4-dev (>= 2.12.8), libgda3-dev (>= 3.0.0)
Suggests: libgdamm-3.0-doc
Description: C++ wrappers for libgda (library headers)
 libgdamm is a set of C++ bindings for the libgda database API.
 .
 This package contains the library headers.

Package: libgdamm3.0-doc
Provides: libgdamm-3.0-doc
Conflicts: libgdamm-3.0-doc (<< 2.9.82-0ubuntu1)
Replaces: libgdamm-3.0-doc (<< 2.9.82-0ubuntu1)
Section: doc
Architecture: all
Description: C++ wrappers for libgda (documentation)
 libgdamm is a set of C++ bindings for the libgda database API.
 .
 This package contains the documentation.

Package: libgdamm-3.0-dev
Architecture: all
Depends: libgdamm3.0-dev
Description: transitional package to new libgdamm naming scheme
 This dummy package is provided to smooth the upgrade to the new libgdamm
 naming scheme.
 .
 This package can be safely removed.

Package: libgdamm-3.0-doc
Architecture: all
Depends: libgdamm3.0-doc
Description: transitional package to new libgdamm naming scheme
 This dummy package is provided to smooth the upgrade to the new libgdamm
 naming scheme.
 .
 This package can be safely removed.

[Daniel Holbach (dholbach)]

The transitional packages are not necessary.

[Chris Brotherton (protonchris)]

Thanks, Daniel. Here is an update package with conflicts/replaces fields for the -dev and -doc binary packages, but without the unnecessary transitional packages.

[Xiyue Deng (manphiz)]

libgdamm3.0 3.0.0-1 has already be accepted into Debian repository
pool. Don't know whether it's still possible to begin the sync with
Ubuntu?

[StefanPotyra (sistpoty)]

yes, and I guess we should do so. Since it's the stable release, I'll give ACK #1 on this w.o. needing to revisit diffstat etc.

[Daniel Holbach (dholbach)]

Looks like it's another soname bump (among other changes).

[Chris Brotherton (protonchris)]

I have a question regarding the debian package. In the control file, there is the following entry for the libgdamm3.0-10 binary package:

----------------------------------------------------------------------------------------------
Package: libgdamm3.0-10
Architecture: any
Conflicts: libgdamm3.0-8,
           libgdamm-3.0-8,
           libgdamm3.0-9
Replaces: libgdamm3.0-8,
          libgdamm-3.0-8,
          libgdamm3.0-9
Depends: ${misc:Depends},
         ${shlibs:Depends}
Description: C++ wrappers for libgda3
 libgdamm is a set of C++ bindings for the libgda3 database API.
 libgda is the GNU Data Access library.
 .
 This package contains the shared library.
-----------------------------------------------------------------------------------------------------

Based on the discussion above (StefanPotyra et. al.), I was under the impression that there should not be conflicts/replaces fields for a library package with a soname bump since it might lead to breakage. What am I missing?

libgdamm3.0_2.9.82-0ubuntu2 was uploaded yesterday. So the problems with the conflicts/replaces fields for the -dev and -doc binary packages has been corrected. However, having the stable release of the library is probably a good idea.

[StefanPotyra (sistpoty)]

Oh, indeed, there should be only conflicts/replaces against the -dev/-doc package and not against the library package. Deng, can you fix this in unstable? Thanks!

[Xiyue Deng (manphiz)]

Chris Brotherton <email address hidden> writes:

> I have a question regarding the debian package. In the control file,
> there is the following entry for the libgdamm3.0-10 binary package:
>
> ----------------------------------------------------------------------------------------------
> Package: libgdamm3.0-10
> Architecture: any
> Conflicts: libgdamm3.0-8,
> libgdamm-3.0-8,
> libgdamm3.0-9
> Replaces: libgdamm3.0-8,
> libgdamm-3.0-8,
> libgdamm3.0-9
> Depends: ${misc:Depends},
> ${shlibs:Depends}
> Description: C++ wrappers for libgda3
> libgdamm is a set of C++ bindings for the libgda3 database API.
> libgda is the GNU Data Access library.
> .
> This package contains the shared library.
> -----------------------------------------------------------------------------------------------------
>
> Based on the discussion above (StefanPotyra et. al.), I was under the
> impression that there should not be conflicts/replaces fields for a
> library package with a soname bump since it might lead to breakage.
> What am I missing?
>

They should be "Conflicts/Replaces"ed, because they have the same
contents. Installing them in parallel will fail. And 2.9.82-0ubuntu1
doesn't have the problem when installed in parallel with
2.9.81-0ubuntu1 is because the soname changed since 2.9.82: The
additional "-".

> libgdamm3.0_2.9.82-0ubuntu2 was uploaded yesterday. So the problems
> with the conflicts/replaces fields for the -dev and -doc binary packages
> has been corrected. However, having the stable release of the library
> is probably a good idea.
>
> --
> Request: Upgrade libgdamm3.0 to upstream version 2.9.81
> https://bugs.launchpad.net/bugs/190744
> You received this bug notification because you are a direct subscriber
> of the bug.

[StefanPotyra (sistpoty)]

Hi,

On Wednesday 19 March 2008 13:02:28 Deng Xiyue wrote:
[..]
>
> They should be "Conflicts/Replaces"ed, because they have the same
> contents.

Erm, the *library* package mustn't have overlapping files for different
SONAME's, and it looks like the unstable package correctly doesn't:

dpkg -c libgdamm3.0-10_3.0.0-1_i386.deb
drwxr-xr-x root/root 0 2008-03-17 09:46 ./
drwxr-xr-x root/root 0 2008-03-17 09:46 ./usr/
drwxr-xr-x root/root 0 2008-03-17 09:47 ./usr/lib/
-rw-r--r-- root/root 769704 2008-03-17
09:47 ./usr/lib/libgdamm-3.0.so.10.0.0
drwxr-xr-x root/root 0 2008-03-17 09:46 ./usr/share/
drwxr-xr-x root/root 0 2008-03-17 09:46 ./usr/share/doc/
drwxr-xr-x root/root 0 2008-03-17
09:47 ./usr/share/doc/libgdamm3.0-10/
-rw-r--r-- root/root 1348 2008-03-17
09:42 ./usr/share/doc/libgdamm3.0-10/changelog.Debian.gz
-rw-r--r-- root/root 104 2008-02-23
17:56 ./usr/share/doc/libgdamm3.0-10/README
-rw-r--r-- root/root 630 2008-02-23
17:56 ./usr/share/doc/libgdamm3.0-10/TODO
-rw-r--r-- root/root 2211 2008-03-17
09:42 ./usr/share/doc/libgdamm3.0-10/copyright
-rw-r--r-- root/root 47 2008-02-23
17:56 ./usr/share/doc/libgdamm3.0-10/AUTHORS
-rw-r--r-- root/root 2585 2008-03-16
14:35 ./usr/share/doc/libgdamm3.0-10/NEWS.gz
-rw-r--r-- root/root 13828 2008-03-16
14:35 ./usr/share/doc/libgdamm3.0-10/changelog.gz
lrwxrwxrwx root/root 0 2008-03-17
09:46 ./usr/lib/libgdamm-3.0.so.10 -> libgdamm-3.0.so.10.0.0

Cheers,
      Stefan.

[Xiyue Deng (manphiz)]

StefanPotyra <email address hidden> writes:

> Hi,
>
> On Wednesday 19 March 2008 13:02:28 Deng Xiyue wrote:
> [..]
>>
>> They should be "Conflicts/Replaces"ed, because they have the same
>> contents.
>
> Erm, the *library* package mustn't have overlapping files for different
> SONAME's, and it looks like the unstable package correctly doesn't:
>

Oops, I forgot the soversion bump between 2.9.82 and 3.0.0. Sorry.
Fixing right away...

[Scott Kitterman (kitterman)]

Axk #2 and approved. someone mark confirmed please.

[StefanPotyra (sistpoty)]

>
> Oops, I forgot the soversion bump between 2.9.82 and 3.0.0. Sorry.
> Fixing right away...

Excellent, thanks!

Cheers,
      Stefan.

[Chris Brotherton (protonchris)]

Should I keep this bug open or submit a new one for a debian unstable sync request?

Also, once we sync, I will make sure the glom package is updated to build against the new version of the library. So far, glom is the only package the reverse depends on libgdam3.0.

Chris.

[Chris Brotherton (protonchris)]

I'll leave this one open since it has already received two ACKs and been approved by the motu-release team. Thanks.

[Chris Brotherton (protonchris)]

Please sync libgdamm3.0 3.0.0-2 from Debian unstable. The 3.0.0 release is considered a stable release and would be a good addition to hardy. After the binary package name change that took place in libgdamm3.0_2.9.82-0ubuntu1, the names of the ubuntu and debian packages are the same.

The motu-release team has already approved the freeze exception for this sync (see above).

Package changelog:

 libgdamm3.0 (3.0.0-2) unstable; urgency=low

   * Drop Conflicts/Replaces from shared library package. They should be
     able to install in parallel.
   * Add `DM-Upload-Allowed: yes' field. Thanks Loïc for advocacy.

 -- Deng Xiyue <email address hidden> Wed, 19 Mar 2008 20:47:11 +0800

libgdamm3.0 (3.0.0-1) unstable; urgency=low

   * New upstream release.
     + Bump soversion to 10 to match upstream changes.
     + Add proper Conflicts/Replaces to prepare for sync from Ubuntu.
   * Add Debian GNOME Team as uploader.
   * Refine debian/rules to be consistent with other GNOME Packages:
     + Use gnome-pkg-tools, and set GNOME_MODULE := libgdamm
     + Set shlibs version to 3.0.0 due to new API.
     + Set proper exclude rules.
     + Use chrpath hack to get rid of rpath on 64bit system.
     + Bump compat level to 6, and b-dep on debhelper >= 6, cdbs >= 0.4.51.
   * Refine debian/control*:
     + Add chrpath, gnome-pkg-tools to Build-depends.
     + Wrap fields for easier patch.
     + Add ${misc:Depends} and ${shlibs:Depends} to Depends.
   * Add libgdamm-3.0-doc.doc-base.libgdamm3.0-reference.
   * Add libgdamm-3.0-doc.examples to ship examples.
   * Refine libgdamm-3.0-doc.docs install path to retain original directory
     hierarchy.
   * Refine watch file.

 -- Deng Xiyue <email address hidden> Mon, 17 Mar 2008 10:09:54 +0800

 libgdamm3.0 (2.9.81-1) unstable; urgency=low

   * Import Ubuntu package in Debian
   * New upstream version.
   * Change Maintainer address to point at me
   * Update Standars-Version to 3.7.3. No changes needed.
   * Change how binary packages are named, from libgdamm-3.0 to libgdamm3.0
   * Change package descriptions to made them more similar to the ones included
   in libgdamm1.3 package.

 -- Jose Carlos Garcia Sogo <email address hidden> Sun, 10 Feb 2008 17:01:48 +0100

[Chris Brotherton (protonchris)]

The only rdepends for this package is glom and I plan on submitting a new glom package that includes a new upstream release and builds against the new libgdamm3.0 package (Bug 204039).

[Chris Brotherton (protonchris)]

Build log of libgdamm3.0 3.0.0-2 on hardy.

[StefanPotyra (sistpoty)]

sponsors ACK for the sync.

[Chris Brotherton (protonchris)]

The libgdamm3.0 package was recently added to Debian. The version in unstable (3.0.0) is considered a stable release of the library. Previously, the binary package names in ubuntu and debian differed, but the recent version of libgdamm3.0 in ubuntu changed the package names to be in line with debian.

The debian package started out as a sync from ubuntu (see changelog above).

[Jonathan Riddell (jr)]

Getting binaries for hardy...
[Updating] libgdamm3.0 (2.9.82-0ubuntu2 [Ubuntu] < 3.0.0-2 [Debian])
 * Trying to add libgdamm3.0...
  - <libgdamm3.0_3.0.0-2.dsc: downloading from http://ftp.debian.org/debian/>
  - <libgdamm3.0_3.0.0.orig.tar.gz: downloading from http://ftp.debian.org/debian/>
  - <libgdamm3.0_3.0.0-2.diff.gz: downloading from http://ftp.debian.org/debian/>