Re: Fwd: Re: unable to execute
On Tue, 28 Mar 2000, Tristan Savatier wrote:
>> It works (well runs, I have no VCDs to test with at work) and display
>> help (mtvp -h). Even the graphical intreface works too. That .deb was
>> mtv_1.1.0.20-2_i386.deb
>>
>> When I install the glibc2.1 version (mtv_1.1.0.20-3_i386.deb) it
>> promptly fails. You don't seem to have any dependancy information in
>> your .deb's which is probably a bad thing.
>
>Our deb package files are derived from our RPM's using the
>'alien' script. Looks like alien is not perfect.
Of course alien can't maintain dependencies. The packages don't always have
the same names in different distributions, and there is not always a 1:1
mapping of packages. A set of programs that is one package in Red Hat might
be 3 packages in Debian.
>> Debian 2.1 ships with libc6-2.0.7.19981211-6; Corel has the same
>> version. Debian 2.2 has libc6-2.1.3-7 (currently). Perhaps depending
>> on the right version of the libc6 would be good.
>
>yes, but that would force us to make debian-specific packages.
>we don't want that. we want RPM to be our master packages,
>and we convert to other formats (DEB, SLP) using alien.
Which of course makes things harder for everyone. Really it's not that
difficult to add a debian/ directory into the source tree. I'm sure that
there's plenty of volunteers to do it for you.
You can easily setup a basic Debian development environment in a chroot
directory on your Red Hat system and then compile native Debian packages with
all correct dependencies and save such problems in future.
>> > usually when this type of thing happens, it is something
>> > broken with the libraries. mtvp is one of the few multithreaded
>> > applications, and anything broken in the thread support would be fatal
>> > for mtvp.
>>
>> They've installed the wrong version; perhaps updating your ver web
>> site with information for Corel would be useful too.
>
>certainely a good idea. we'll do that. thanks for your help
>understanding the situation. still, I don't fully understand
>why glibc2.1 and glibc2.0 are not binary (API) compatible ?
>It looks like a major problem to me, and causes havoc again
>(I mean, after the glibc2.0/libc5 incompatibility).
IMHO going from libc5 to libc6 was a non-issue. You can have both versions
installed on the same machine. Each program will be linked exclusively with
one or the other. So it's no big deal. Glibc2 to Glibc2.1 uses the same SO
major numbers so you can't install both at once and it sometimes breaks
things. This is annoying.
--
My current location - X marks the spot.
X
X
X
Reply to: