Hi folks,
you may have noticed Oracle released db-4.6.18 recently. The update is now prepared in CVS, old db-4.5.20 is now moved to compat-db so the new db4 is ready to hit rawhide soon.
I want to announce a change I made in the new db4, that may affect you from the packaging POV if your package is dependent on db4. It is that I moved all the C++ stuff to db4-cxx and db4-cxx-devel subpackages to reduce dependency bloat (#220484).
If you have any proposals/objections related to the update, please speak up.
Thanks, Jindrich
Hi,
On Thu, Aug 09, 2007 at 11:01:00AM +0200, Jindrich Novy wrote:
you may have noticed Oracle released db-4.6.18 recently. The update is now prepared in CVS, old db-4.5.20 is now moved to compat-db so the new db4 is ready to hit rawhide soon.
I want to announce a change I made in the new db4, that may affect you from the packaging POV if your package is dependent on db4. It is that I moved all the C++ stuff to db4-cxx and db4-cxx-devel subpackages to reduce dependency bloat (#220484).
If you have any proposals/objections related to the update, please speak up.
I can understand the splitting of the runtime bits, but why split the *-devel package?
If we start splitting devel we would need guidelines as to how far to split: foo-cxx-devel, foo-f90-devel, foo-python-devel? Or foo-gtk-devel, foo-qt-devel, foo-cxx-qt-3-but-not-4-devel etc.
foo-devel is currently sacred, even library packages w/o such a subpackage have to provide it so, the packagers of build-dependent packages can simply trust that
BR: foo-devel
will ensure the bits are there. Now they would have to check whether foo has foo-cxx-devel, too, and whether that goes unnoticed by their bar detection scripts (e.g. bar just simlently builds C bindings etc).
On Thu, 2007-08-09 at 14:27 +0200, Axel Thimm wrote:
Hi,
On Thu, Aug 09, 2007 at 11:01:00AM +0200, Jindrich Novy wrote:
you may have noticed Oracle released db-4.6.18 recently. The update is now prepared in CVS, old db-4.5.20 is now moved to compat-db so the new db4 is ready to hit rawhide soon.
I want to announce a change I made in the new db4, that may affect you from the packaging POV if your package is dependent on db4. It is that I moved all the C++ stuff to db4-cxx and db4-cxx-devel subpackages to reduce dependency bloat (#220484).
If you have any proposals/objections related to the update, please speak up.
I can understand the splitting of the runtime bits, but why split the *-devel package?
+1. Splitting the -devel package is a rather significant alteration, for little benefit (and shouldn't increase dependency bloat).
~spot
packaging@lists.fedoraproject.org