Hi all,
it seems to be the right time to do an unification/reorganization of Oracle (Berkeley) DB packages in rawhide. The current situation is that there are three of them:
compat-db - shipping old libdbs for compatibility (4.5,4.6 and 4.7) db4 - shipping latest 4.x libdb series (4.8) libdb - shipping latest libdb release (5.3)
What I'm planning to do is getting rid of db4 package. But before that I want to clean-up compat-db for a bit.
After fiddling a bit with repoquery nothing seems to be dependent on libdb-4.5 so if there are no objections I want to remove it.
There was only one package dependent on 4.6 (squidGuard) because it had compilation problems with 4.7. This package is now built against 5.3 with no problem so 4.6 could go away from compat-db as well.
Only one package (pam_abl-0:0.2.3-8.fc12) was dependent on 4.7 in Fedora 17 but it's already rebuilt in rawhide so 4.7 can go away as well.
So the plan is: 1) remove 4.5, 4.6 and 4.7 from compat-db 2) put 4.8 to compat-db 3) make db4 a dead package (db4 package name is not very descriptive any more as we have libdb-5.3 ...)
The reason I'm sending this to fedora-devel is that I'm unable to reveal dlopen() or similar deps in packages so if your package requires older libdb I plan to remove and can not be rebuilt against newer libdb then please speak up!
Thanks, Jindrich
On Tue, Apr 17, 2012 at 7:21 AM, Jindrich Novy jnovy@redhat.com wrote:
Hi all,
it seems to be the right time to do an unification/reorganization of Oracle (Berkeley) DB packages in rawhide. The current situation is that there are three of them:
compat-db - shipping old libdbs for compatibility (4.5,4.6 and 4.7) db4 - shipping latest 4.x libdb series (4.8) libdb - shipping latest libdb release (5.3)
What I'm planning to do is getting rid of db4 package. But before that I want to clean-up compat-db for a bit.
After fiddling a bit with repoquery nothing seems to be dependent on libdb-4.5 so if there are no objections I want to remove it.
There was only one package dependent on 4.6 (squidGuard) because it had compilation problems with 4.7. This package is now built against 5.3 with no problem so 4.6 could go away from compat-db as well.
Only one package (pam_abl-0:0.2.3-8.fc12) was dependent on 4.7 in Fedora 17 but it's already rebuilt in rawhide so 4.7 can go away as well.
So the plan is:
- remove 4.5, 4.6 and 4.7 from compat-db
- put 4.8 to compat-db
- make db4 a dead package
(db4 package name is not very descriptive any more as we have libdb-5.3 ...)
The reason I'm sending this to fedora-devel is that I'm unable to reveal dlopen() or similar deps in packages so if your package requires older libdb I plan to remove and can not be rebuilt against newer libdb then please speak up!
Please have a look at this, seems like a good time to get it out of the way.
https://bugzilla.redhat.com/show_bug.cgi?id=225647
Thanks!
-J
Thanks, Jindrich
-- Jindrich Novy jnovy@redhat.com http://people.redhat.com/jnovy/ Kdo víno má a nepije, kdo hrozny má a nejí je, kdo ženu má a nelíbá, kdo zábavě se vyhýbá, na toho vemte bič a hůl, to není člověk, to je vůl.
--- Jan Werich
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Apr 17, 2012 at 02:21:36PM +0200, Jindrich Novy wrote:
So the plan is:
- remove 4.5, 4.6 and 4.7 from compat-db
- put 4.8 to compat-db
- make db4 a dead package (db4 package name is not very descriptive any more as we have libdb-5.3 ...)
Sounds great. For Fedora 17 also, right? #768846 is bad.
Regards, Joe
On Tue, Apr 17, 2012 at 3:10 PM, Joe Orton jorton@redhat.com wrote:
On Tue, Apr 17, 2012 at 02:21:36PM +0200, Jindrich Novy wrote:
So the plan is:
- remove 4.5, 4.6 and 4.7 from compat-db
- put 4.8 to compat-db
- make db4 a dead package
(db4 package name is not very descriptive any more as we have libdb-5.3 ...)
Sounds great. For Fedora 17 also, right? #768846 is bad.
No! Changes of this level should only be done for rawhide, F-17 is in stabilisation stage.
Peter
On Tue, Apr 17, 2012 at 9:24 AM, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Apr 17, 2012 at 3:10 PM, Joe Orton jorton@redhat.com wrote:
On Tue, Apr 17, 2012 at 02:21:36PM +0200, Jindrich Novy wrote:
So the plan is:
- remove 4.5, 4.6 and 4.7 from compat-db
- put 4.8 to compat-db
- make db4 a dead package
(db4 package name is not very descriptive any more as we have libdb-5.3 ...)
Sounds great. For Fedora 17 also, right? #768846 is bad.
No! Changes of this level should only be done for rawhide, F-17 is in stabilisation stage.
I'm not authorized to see 768846, but unless it's a showstopping bugfix or security fix, I concur with Peter.
-J
Peter
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Apr 17, 2012 at 09:27:23AM -0500, Jon Ciesla wrote:
On Tue, Apr 17, 2012 at 9:24 AM, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Apr 17, 2012 at 3:10 PM, Joe Orton jorton@redhat.com wrote:
On Tue, Apr 17, 2012 at 02:21:36PM +0200, Jindrich Novy wrote:
So the plan is:
- remove 4.5, 4.6 and 4.7 from compat-db
- put 4.8 to compat-db
- make db4 a dead package
(db4 package name is not very descriptive any more as we have libdb-5.3 ...)
Sounds great. For Fedora 17 also, right? #768846 is bad.
No! Changes of this level should only be done for rawhide, F-17 is in stabilisation stage.
I'm not authorized to see 768846, but unless it's a showstopping bugfix or security fix, I concur with Peter.
It looks like it's open to everyone now. Basically, perl and perl-BerkeleyDB are linked to different versions of libdb so they can't operate together.
-Toshio
On Tue, Apr 17, 2012 at 02:21:36PM +0200, Jindrich Novy wrote:
Hi all,
it seems to be the right time to do an unification/reorganization of Oracle (Berkeley) DB packages in rawhide. The current situation is that there are three of them:
compat-db - shipping old libdbs for compatibility (4.5,4.6 and 4.7) db4 - shipping latest 4.x libdb series (4.8) libdb - shipping latest libdb release (5.3)
What I'm planning to do is getting rid of db4 package. But before that I want to clean-up compat-db for a bit.
After fiddling a bit with repoquery nothing seems to be dependent on libdb-4.5 so if there are no objections I want to remove it.
There was only one package dependent on 4.6 (squidGuard) because it had compilation problems with 4.7. This package is now built against 5.3 with no problem so 4.6 could go away from compat-db as well.
Only one package (pam_abl-0:0.2.3-8.fc12) was dependent on 4.7 in Fedora 17 but it's already rebuilt in rawhide so 4.7 can go away as well.
So the plan is:
- remove 4.5, 4.6 and 4.7 from compat-db
- put 4.8 to compat-db
- make db4 a dead package (db4 package name is not very descriptive any more as we have libdb-5.3 ...)
Note: traditionally (ie: this isn't a guideline but it's been traditional and we could look into making it a guideline), the compat-* name is used for libraries that we're shipping that you cannot build against in Fedora. So we would not ship header files for it. The idea of compat-* packages is that programs compiled outside of the distro may need to use the older version of the library so we keep the library around for a release or two.
For libraries that we're keeping around where we do want to build against them, we name them with the version number.
So, instead of making db4 a dead package and keeping compat-db, it makes more sense to make compat-db the dead package and keep the db4 name. The contents of the new db4 package would be very close to what's in the present compat-db package; we're just trying to make the name switch over.
Another, related note: Since this package was named compat-db to begin with, is part of its reason for existence that we want non-Fedora packages compiled against older libdb to run? If so, it's not sufficient to check what things in Fedora need an older version of libdb before removing it from the compat package.
-Toshio
On 2012-04-17, Jindrich Novy jnovy@redhat.com wrote:
it seems to be the right time to do an unification/reorganization of Oracle (Berkeley) DB packages in rawhide.
[...]
What I'm planning to do is getting rid of db4 package. But before that I want to clean-up compat-db for a bit.
Is it possible to handle db4-created database file with db5 library? In other words, if I rebuild an aplication against db5 and ship it to stable Fedora, can I expect problems?
-- Petr
Hi Petr,
On Thu, Apr 19, 2012 at 06:57:11AM +0000, Petr Pisar wrote:
On 2012-04-17, Jindrich Novy jnovy@redhat.com wrote:
it seems to be the right time to do an unification/reorganization of Oracle (Berkeley) DB packages in rawhide.
[...]
What I'm planning to do is getting rid of db4 package. But before that I want to clean-up compat-db for a bit.
Is it possible to handle db4-created database file with db5 library? In other words, if I rebuild an aplication against db5 and ship it to stable Fedora, can I expect problems?
Oracle tries to keep the old on-disk format readable and usable by the next libdb releases. From what I see from the changelogs:
http://www.oracle.com/technetwork/database/berkeleydb/downloads/index-082944...
The file format of 5.3.x should still be compatible with 4.8.x. Only the log file format upgrade is needed (if used).
Jindrich
-- Petr
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Hi Toshio,
On Wed, Apr 18, 2012 at 09:39:19AM -0700, Toshio Kuratomi wrote:
So the plan is:
- remove 4.5, 4.6 and 4.7 from compat-db
- put 4.8 to compat-db
- make db4 a dead package (db4 package name is not very descriptive any more as we have libdb-5.3 ...)
Note: traditionally (ie: this isn't a guideline but it's been traditional and we could look into making it a guideline), the compat-* name is used for libraries that we're shipping that you cannot build against in Fedora. So we would not ship header files for it. The idea of compat-* packages is that programs compiled outside of the distro may need to use the older version of the library so we keep the library around for a release or two.
This is the reason why I sent this proposal to wider audience before actually doing this change. I'm not sure if anyone from the non-Fedora apps still uses old libdbs and if so, then please let me know.
Many applications requiring libdb (including RPM) allows static link with internal libdb which makes it possible to build such apps even without the requirement of having a particular old version in Fedora.
From my POV it is not needed to support these any more. The hint for
me is number of bugs reported against compat-db in the last years. No one, even from third-parties, seem to use these.
For libraries that we're keeping around where we do want to build against them, we name them with the version number.
So, instead of making db4 a dead package and keeping compat-db, it makes more sense to make compat-db the dead package and keep the db4 name. The contents of the new db4 package would be very close to what's in the present compat-db package; we're just trying to make the name switch over.
Getting rid of the db4 package brings several benefits. Many packagers traditionally have BuildRequires: db4-devel in their spec files even in F17+ and their packages aren't really dependent on 4.x libdb series but just "requires a libdb".
By removing db4 and leaving compat-db (or even libdb4) and libdb in repository without db4-devel provide packagers need to reconsider whether their app still needs to link against obsolete 4.x or is fine with the latest 5.x series upon the next build.
IMO more than 90% will just link against 5.x series. A shining example is squidGuard which was linked against old 4.6 because of build problems against 4.7 from times this version was the main one. It is now rebuilt without changes against 5.3 and seems to work OK.
Another, related note: Since this package was named compat-db to begin with, is part of its reason for existence that we want non-Fedora packages compiled against older libdb to run? If so, it's not sufficient to check what things in Fedora need an older version of libdb before removing it from the compat package.
Maybe we should get rid of both compat-db and db4 and introduce libdb4 for packages requiring this particular version if it turns out some app still needs libdb-4.x for functionality reasons.
Again, if you are a package maintainer of such kind of app please let me know. Try to rebuild your package against libdb-5. If everything is rebuildable and fully functional with libdb-5.x then we don't even need a libdb4 package.
Jindrich
On Thu, Apr 19, 2012 at 01:02:37PM +0200, Jindrich Novy wrote:
Maybe we should get rid of both compat-db and db4 and introduce libdb4 for packages requiring this particular version if it turns out some app still needs libdb-4.x for functionality reasons.
+1
This sounds like the best course to me.
-Toshio
On Tue, 17 Apr 2012 15:24:17 +0100, PR (Peter) wrote:
On Tue, Apr 17, 2012 at 3:10 PM, Joe Orton wrote:
On Tue, Apr 17, 2012 at 02:21:36PM +0200, Jindrich Novy wrote:
So the plan is:
- remove 4.5, 4.6 and 4.7 from compat-db
- put 4.8 to compat-db
- make db4 a dead package
(db4 package name is not very descriptive any more as we have libdb-5.3 ...)
Sounds great. For Fedora 17 also, right? #768846 is bad.
No! Changes of this level should only be done for rawhide, F-17 is in stabilisation stage.
The libdb packaging in F-17 is broken. Several things in the spec file simply don't make any sense. Major changes are needed to fix that. Additionally, there are lots of implicit conflicts with db4* in the subpackages. With bug reports in bugzilla even.
On 05/04/2012 12:23 PM, Michael Schwendt wrote:
On Tue, 17 Apr 2012 15:24:17 +0100, PR (Peter) wrote:
On Tue, Apr 17, 2012 at 3:10 PM, Joe Orton wrote:
On Tue, Apr 17, 2012 at 02:21:36PM +0200, Jindrich Novy wrote:
So the plan is:
- remove 4.5, 4.6 and 4.7 from compat-db
- put 4.8 to compat-db
- make db4 a dead package (db4 package name is not very descriptive any more as we have libdb-5.3 ...)
Sounds great. For Fedora 17 also, right? #768846 is bad.
No! Changes of this level should only be done for rawhide, F-17 is in stabilisation stage.
The libdb packaging in F-17 is broken. Several things in the spec file simply don't make any sense. Major changes are needed to fix that. Additionally, there are lots of implicit conflicts with db4* in the subpackages. With bug reports in bugzilla even.
Rawhide is in bad shape too:
https://bugzilla.redhat.com/show_bug.cgi?id=816284
Transaction Check Error: file /usr/include/db.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_185.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_cxx.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/lib64/libdb.so conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64
On Wed, Jun 13, 2012 at 09:44:37 -0600, Orion Poplawski orion@cora.nwra.com wrote:
On 05/04/2012 12:23 PM, Michael Schwendt wrote:
Rawhide is in bad shape too:
https://bugzilla.redhat.com/show_bug.cgi?id=816284
Transaction Check Error: file /usr/include/db.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_185.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_cxx.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/lib64/libdb.so conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64
My memory is that db4 was going to be retired in F18. But it hasn't happened yet.
On 06/13/2012 10:15 AM, Bruno Wolff III wrote:
On Wed, Jun 13, 2012 at 09:44:37 -0600, Orion Poplawski orion@cora.nwra.com wrote:
On 05/04/2012 12:23 PM, Michael Schwendt wrote:
Rawhide is in bad shape too:
https://bugzilla.redhat.com/show_bug.cgi?id=816284
Transaction Check Error: file /usr/include/db.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_185.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_cxx.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/lib64/libdb.so conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64
My memory is that db4 was going to be retired in F18. But it hasn't happened yet.
Looks like RPC is gone from libdb 5. Is there a suggested replacement? Should projects just stop using it?
On Wed, 13 Jun 2012 11:15:08 -0500, Bruno Wolff III wrote:
On Wed, Jun 13, 2012 at 09:44:37 -0600, Orion Poplawski wrote:
On 05/04/2012 12:23 PM, Michael Schwendt wrote:
Rawhide is in bad shape too:
https://bugzilla.redhat.com/show_bug.cgi?id=816284
Transaction Check Error: file /usr/include/db.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_185.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_cxx.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/lib64/libdb.so conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64
My memory is that db4 was going to be retired in F18. But it hasn't happened yet.
There is a Rename Request for db4 -> libdb4 in the package review queue: https://bugzilla.redhat.com/816124
That's where all the fun related to the packaging conflicts and errors takes places. ;)
On 06/13/2012 09:44 AM, Orion Poplawski wrote:
On 05/04/2012 12:23 PM, Michael Schwendt wrote:
On Tue, 17 Apr 2012 15:24:17 +0100, PR (Peter) wrote:
On Tue, Apr 17, 2012 at 3:10 PM, Joe Orton wrote:
On Tue, Apr 17, 2012 at 02:21:36PM +0200, Jindrich Novy wrote:
So the plan is:
- remove 4.5, 4.6 and 4.7 from compat-db
- put 4.8 to compat-db
- make db4 a dead package (db4 package name is not very descriptive any more as we have libdb-5.3 ...)
Sounds great. For Fedora 17 also, right? #768846 is bad.
No! Changes of this level should only be done for rawhide, F-17 is in stabilisation stage.
The libdb packaging in F-17 is broken. Several things in the spec file simply don't make any sense. Major changes are needed to fix that. Additionally, there are lots of implicit conflicts with db4* in the subpackages. With bug reports in bugzilla even.
Rawhide is in bad shape too:
https://bugzilla.redhat.com/show_bug.cgi?id=816284
Transaction Check Error: file /usr/include/db.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_185.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_cxx.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/lib64/libdb.so conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64
Still the same....
On Mon, 09 Jul 2012 14:51:09 -0600, Orion Poplawski wrote:
Transaction Check Error: file /usr/include/db.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_185.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_cxx.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/lib64/libdb.so conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64
Still the same....
Which is because libdb4 (the db4 rename) has not landed yet. Package review request: https://bugzilla.redhat.com/816124
-
Bruno Wolff III -
Jindrich Novy -
Joe Orton -
Jon Ciesla -
Michael Schwendt -
Orion Poplawski -
Peter Robinson -
Petr Pisar -
Toshio Kuratomi