Re: upcoming libdb/db4/compat-db reorganization

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

 



Hi Toshio,

On Wed, Apr 18, 2012 at 09:39:19AM -0700, Toshio Kuratomi wrote:
> > 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 ...)
> > 
> 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

-- 
Jindrich Novy <jnovy@xxxxxxxxxx>   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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux