11:56 a.m.
For upgrading readline to a new major release (in Fedora development),
do I need to provide a readline4 package, or is it sufficient to just
rebuild the packages that depend on it?
Tim.
*/
12:14 p.m.
Tim Waugh (twaugh(a)redhat.com) said:
For upgrading readline to a new major release (in Fedora
development),
do I need to provide a readline4 package, or is it sufficient to just
rebuild the packages that depend on it?
A compat library may be nice, considering the number of apps that link
against it.
Bill
12:33 p.m.
On Thursday 09 December 2004 02:14, Bill Nottingham wrote:
> For upgrading readline to a new major release (in Fedora
> development), do I need to provide a readline4 package, or is it
> sufficient to just rebuild the packages that depend on it?
A compat library may be nice, considering the number of apps that
link against it.
Check ABI compat within pkg first. Eg, you can link python 1.5 against
db4 cuz db4 has db1-ish stuff still. Reduction of compat madness is
optimal.
have fun,
--
-jeff
1:11 p.m.
Tim Waugh wrote:
For upgrading readline to a new major release (in Fedora
development),
do I need to provide a readline4 package, or is it sufficient to just
rebuild the packages that depend on it?
Prolly.
Alternatively, if the API changes aren't seriously different, you might just
as well add versioned symbols so that we can get rid of all this
compat-baggage
once and for all, and provide an explicit and trackable ABI in the same
soname
just like glibc does.
See elfutils for hints on serious and sober use of versioned symbols.
FWIW, I'm convinced that libselinux is going to need to undertake versioned
symbols Real Soon Now as well, bit that's fedora-selinux, not
fedora-devel, fodder.
73 de Jeff
8:54 a.m.
On Wed, 08 Dec 2004 14:11:14 -0500, Jeff Johnson wrote:
Alternatively, if the API changes aren't seriously different, you
might just
as well add versioned symbols so that we can get rid of all this
compat-baggage
once and for all, and provide an explicit and trackable ABI in the same
soname
just like glibc does.
Eek no, please don't.
(a) It's not portable, so it means forking upstream
(b) Symbol overloading is confusing for people and practically nobody
understands how to select a particular version at compile time.
If the API changed that is essential otherwise you won't be able
to build apps using the older API on newer systems.
Actually providing one version per symbol though is a good idea (and it's
more portable), and hopefully more libraries will do it in future. The
benefits of providing multiple versions per symbol is something I was
never convinced about given the costs. Just provide two packages and
install them both.
9:10 a.m.
On Thu, Dec 09, 2004 at 02:33:19AM +0800, Jeff Pitman wrote:
On Thursday 09 December 2004 02:14, Bill Nottingham wrote:
> > For upgrading readline to a new major release (in Fedora
> > development), do I need to provide a readline4 package, or is it
> > sufficient to just rebuild the packages that depend on it?
>
> A compat library may be nice, considering the number of apps that
> link against it.
Check ABI compat within pkg first. Eg, you can link python 1.5 against
db4 cuz db4 has db1-ish stuff still. Reduction of compat madness is
optimal.
No, the soname has definitely changed incompatibly. I'll have a go at
making a readline43 package.
Tim.
*/
7038
days inactive
7072
days old
5 comments
5 participants
participants (5)
-
Bill Nottingham -
Jeff Johnson -
Jeff Pitman -
Mike Hearn -
Tim Waugh