Re: Debian-Alpha port ideas...please read (long)
On Thu, 30 Oct 1997, Doug DeJulio wrote:
> Since you're asking for opinions...
> Let me see if I understand the issue correctly.
> * The i86 folks are switching to glibc, from the old Linux C library.
> * The new library is not compatible with the old library, and so needs to be
> distinguished strongly -- anything depending on the old one just won't work
> with the new one.
> * Alpha folks have been using gnu libc all along. There's no incompatability;
> the only reason to switch the names is to be consistent with the i86 folks.
> Packages linked against non-g versions of libraries will in fact work with
> the g versions -- the dependency mechanism just thinks they won't.
Right. Another problem, from an Alpha repackager's standpoint is that
many x86 maintainers have written their debian/rules files (essentially, a
big build script to build packages and such) to generate both "g" and
non-g versions of the libraries by default instead of analysing the
architecture and/or libc5 availability first. This means that anyone
running a purely libc6/glibc x86 that wants to recompile their own
packages will have the same problems as we're having on the back end.
I've had to spend up to an hour editing a package or two just to get the
thing to build properly and package. Frequently, I just let it bomb on
the libc5-compat stuff and do the rest by hand, which is sub-optimal.
> So, the big reasons for Alpha folks *not* to use the "g" is (1) aesthetics,
> and (2) compatability with packages compiled before the renaming. Right?
Actually, the reasoning above is a third, but it's really only a
packager's problem. Also, aesthetics really doesn't play into it since
I doubt any of us really care what the libs are named so long as they work
and the dependencies don't get mangled, as they are right now.
> Is it possible for us to package a version that is, say, named with the "g",
> but is labeled such that it *provides* the non-g version? That would let
> packages depend on either without a problem. Similarly, a non-g version could
> claim to provide the g version, with the same result.
That is possible, however, it is not a good time-saving solution and
would also not solve the problem I mentioned above. I think my point in
bringing all of this up was the broken dependency issue as well as airing
my grief over having to hand-edit and build libs packages because the
x86'ers hadn't moved up to glibc. In short, I could easily write a script
to wipe the "g" designation from a package, but alot of the other
solutions that I considered would require more personal intervention. I
really would like to find a good solution to suggest to the x86
maintainers that would allow them to compile their packages automatically
on a fakeroot-equipped Alpha without intervention. The way things are
now, that's just not possible for any libs package.
> If that's possible, then the only real things influencing the choice are
> aesthetics and accross-the-board compatability. It's a close call, but I'd
> have to go with compatability and go for the "g" version as default -- as long
> as the non-g version was "provided".
I'm beginning to agree. We need to get these "g" libs compiled, and
there is no doubt that we can do it, but I'm worried about breaking the
things that we may not have patches for (example only, I have no patches
for gdb, ldso, and quite a few others). The Provides idea is pretty sound
on our platform, though. It's an interesting thought. I'll have to try
it with a few packages to see how well it works.
> Or do I not correctly understand how Debian package dependancies work? I
> admit, I haven't yet built a package myself.
You pretty much hit the nail on the head regarding understanding the
packaging problem. Thanks for the comments. You brought up an option
that I hadn't thought of before....
Chris
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-alpha-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: