db-compat
 

Hi,

It would seem we're no longer shipping libdb-4.1.so, whereas we do have
4.2, 4.3, and 4.5 in that db4 compatibility package. I wound up just
stealing the binary from an older RPM and copying it in place.

Anyway, software like Xilinx's ISE/EDK would like it back :)

Jon.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

db-compat
 

On Mon, Nov 10, 2008 at 6:02 AM, Jon Masters <jonathan@jonmasters.org> wrote:
> Hi,
>
> It would seem we're no longer shipping libdb-4.1.so, whereas we do have
> 4.2, 4.3, and 4.5 in that db4 compatibility package. I wound up just
> stealing the binary from an older RPM and copying it in place.
>
> Anyway, software like Xilinx's ISE/EDK would like it back :)
>
> Jon.

Jindrich Novy, can you package it for us, please ?
Xilinx ISE/EDK is also an important tool for me :)

Chitlesh

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

db-compat
 

Jon Masters (jonathan@jonmasters.org) said:
> It would seem we're no longer shipping libdb-4.1.so, whereas we do have
> 4.2, 4.3, and 4.5 in that db4 compatibility package. I wound up just
> stealing the binary from an older RPM and copying it in place.
>
> Anyway, software like Xilinx's ISE/EDK would like it back :)

So, this is software that hasn't been rebuilt since RHEL 3 (or an
equivalent thereof.) We certainly don't support Fedora releases that
far back.

Bill

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

db-compat
 

On Mon, 2008-11-10 at 12:17 -0500, Bill Nottingham wrote:
> Jon Masters (jonathan@jonmasters.org) said:
> > It would seem we're no longer shipping libdb-4.1.so, whereas we do have
> > 4.2, 4.3, and 4.5 in that db4 compatibility package. I wound up just
> > stealing the binary from an older RPM and copying it in place.
> >
> > Anyway, software like Xilinx's ISE/EDK would like it back :)
>
> So, this is software that hasn't been rebuilt since RHEL 3 (or an
> equivalent thereof.) We certainly don't support Fedora releases that
> far back.

What, db-compat, or the SO in question?

Jon.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

db-compat
 

Jon Masters (jcm@redhat.com) said:
> > So, this is software that hasn't been rebuilt since RHEL 3 (or an
> > equivalent thereof.) We certainly don't support Fedora releases that
> > far back.
>
> What, db-compat, or the SO in question?

db-4.1 was last the system DB library in RHEL 3/FC1.

Bill

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

db-compat
 

On 11/10/2008 11:30 PM, Bill Nottingham wrote:
Jon Masters (jcm@redhat.com) said:


So, this is software that hasn't been rebuilt since RHEL 3 (or an
equivalent thereof.) We certainly don't support Fedora releases that
far back.


What, db-compat, or the SO in question?



db-4.1 was last the system DB library in RHEL 3/FC1.

For ther record: compat-db-4.1.25-9.i386.rpm is available in RHEL 4.
and it works OK in RHEL 5 (I have a commercial EDA tool which claims
RHEL5 compatibility but does not work without this lib)


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

db-compat
 

On Tue, 2008-11-11 at 00:23 +0200, Manuel Wolfshant wrote:
> On 11/10/2008 11:30 PM, Bill Nottingham wrote:
> > Jon Masters (jcm@redhat.com) said:
> >
> >>> So, this is software that hasn't been rebuilt since RHEL 3 (or an
> >>> equivalent thereof.) We certainly don't support Fedora releases that
> >>> far back.
> >>>
> >> What, db-compat, or the SO in question?
> >>
> >
> > db-4.1 was last the system DB library in RHEL 3/FC1.

What's the point of a "compat" library if not to support software built
for such systems? We might argue that we only care about F8/F9 and so
start removing other "old" compat libraries, but that's hardly useful.

> For ther record: compat-db-4.1.25-9.i386.rpm is available in RHEL 4.
> and it works OK in RHEL 5 (I have a commercial EDA tool which claims
> RHEL5 compatibility but does not work without this lib)

Indeed. Xilinx claim their tools work on "Red Hat Enterprise
Linux" (which in reality means RHEL4 in this case) but they work fine on
Fedora[0], except for this single library. I just think this is a nice
re-affirmation of the point of compatibility libraries. Once I borrowed
the binary from an older db-compat, place and route works just fine.

Jon.

[0] With the caveat that their setup scripts are some of the worst I've
ever seen. Not handling spaces in automounted CD names results in a need
to copy the CD content/remount, which is so 1970s.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

db-compat
 

Le mardi 11 novembre 2008 Ã* 00:16 -0500, Jon Masters a écrit :
> On Tue, 2008-11-11 at 00:23 +0200, Manuel Wolfshant wrote:

> > > db-4.1 was last the system DB library in RHEL 3/FC1.
>
> What's the point of a "compat" library if not to support software built
> for such systems?

Compat libraries are here to help transitions within the repository,
when some packages have been rebuilt to use the new version and others —
not. They're killed as soon as this transition is complete because:
— compat libraries have their own maintainer cost, and we don't want to
pay it when there are no in-distro users
— as long as they're available there's the risk someone adds a new
package depending on them in the repo, making the transition go
backwards

Thus compat libraries represent a grace period for everyone to
transition gracefully. That some ISVs do not want to understand this and
wait till the grace period is over to realise they need to do some work
is something you should take with those ISVs. Fedora/RHEL provided a
grace period, they chose not to use it.

It's the same problem as users wanting to block xorg releases till
nvidia supported the new APIs, while nvidia waits for new releases to be
official to start working on those APIs.

Bad service from ISVs that do proprietary software, nothing less.

--
Nicolas Mailhot
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

db-compat
 

On Tue, Nov 11, 2008 at 10:18:29AM +0100, Nicolas Mailhot wrote:
>
> Thus compat libraries represent a grace period for everyone to
> transition gracefully. That some ISVs do not want to understand this and
> wait till the grace period is over to realise they need to do some work
> is something you should take with those ISVs. Fedora/RHEL provided a
> grace period, they chose not to use it.

I completly disagree. Not everything needs to be rebuilt to work, compat
libraries are interesting when one wants to avoid to rebuild
applications when the application doesn't change. The other way is to
use static libraries, but this isn't more accepted in fedora.

An example is the numerical models. Once it is built, it is better not
to rebuild it. It may be adapted to the new API and rebuilt, of course,
but if this extra work can be avoided by providing a compat library, it
may be better.

So if maintainers are ready to maintain compat library, let
them do it, it means that it is less work for them than a rebuild of the
application.

--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

db-compat
 

Nicolas Mailhot wrote:

Le mardi 11 novembre 2008 Ã* 00:16 -0500, Jon Masters a écrit :


On Tue, 2008-11-11 at 00:23 +0200, Manuel Wolfshant wrote:





db-4.1 was last the system DB library in RHEL 3/FC1.


What's the point of a "compat" library if not to support software built
for such systems?



Compat libraries are here to help transitions within the repository,
when some packages have been rebuilt to use the new version and others —
not. They're killed as soon as this transition is complete because:
— compat libraries have their own maintainer cost, and we don't want to
pay it when there are no in-distro users
— as long as they're available there's the risk someone adds a new
package depending on them in the repo, making the transition go
backwards

Thus compat libraries represent a grace period for everyone to
transition gracefully. That some ISVs do not want to understand this and
wait till the grace period is over to realise they need to do some work
is something you should take with those ISVs. Fedora/RHEL provided a
grace period, they chose not to use it.

Good luck convincing IBM
(http://www.haifa.ibm.com/projects/verification/RB_Homepage/ ), Cadence
(www.cadence.com) and Synopsys (http://www.synopsys.com/) about that [*]. Until Feb 2008 Rulebase was still built with compatibility with RH9
in mind. The switch to RHEL4 occured less than one year ago. Latest
build (this summer) claims compatibility (as I have said before) with
RHEL5 but needs db-4.1; Synopsys still has NO official support for
anything but RHEL 3.0 / 4.0 (but most of their tools do work on 5);
Cadence has lots of tools which do NOT work on RHEL5. Mentor Graphics
are the only ones who really support RHEL 5 (via static builds)



It's the same problem as users wanting to block xorg releases till
nvidia supported the new APIs, while nvidia waits for new releases to be
official to start working on those APIs.

Bad service from ISVs that do proprietary software, nothing less.

That is correct. Try convincing the hardware industry to not use the
tools from the above vendors, in the context where there are only 3
major players and 2 of them have their own agenda.



--
Manuel Wolfshant linux registered user #131416
IT manager NoBug Consulting SRL
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?




--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list