Re: Debian-Alpha port ideas...please read (long)
On Thu, 30 Oct 1997, Nikita Schmidt wrote:
> Excuse me for deviating from the topic, but what's this ldso you keep
> mentioning? Ldso is obsoleted by glibc (I mean, glibc provides all its
> functionality). We don't need it on Alpha, do we?
Technically and from my understanding, no we don't. Problem is, existing
dependencies. We could either create a stub (there's one now, but it
needs to be updated...should we create one that's versioned like
9999.999-99999?) or just hand-axe the dependencies as we see them. Not
many packages depend on it, but they are out there...
> Umm... The implementations of both approaches (stripping "g" and
> employing Provides:) are almost identical, the main idea being to
> generate the control file from something like control.in with variable
> substitutions, performing architecture dependent variable initialisation
> in the rules file. There is no significant difference in which field is
> going to be patched, Package: or Provides:. (At least I don't see any
> at the moment, leaving aside -p options to dpkg-gencontrol and similar
> small things.)
Well, as far as actually patching the lib packages in question, you're
right about this. However, if this is the approach we agree to, I'd
much rather patch one lib package than have to fix about 10 secondary
pacakges that are generated with fixed dependencies (yes, they're still
out there in numbers despite all conventions....-dev packages are prime
examples).
> We must consider the following.
> 1. Aesthetical reasons:
> - it may be nice to keep the package naming on Alpha as close as
> possible to other platforms (I believe it is pure aesthetics);
> - from the other hand, "g" looks ugly;
Hehehehe... :)
> - with "Provides:", for each "g" package there will be one ghost
> package sitting in the packages database until the transition is
> over.
I don't think this is so evil, but that's just my opinion.
> 2. "Provides:" is obviously a temporary measure which should go away as
> soon as all dependencies are correct. Our grandchildren will eventually
> clean up the corresponding mess in debian/rules, if we happen to be firm
> enough to insist and they do not forget. Renaming packages is kind of a
> "permanent damage" to debian/rules, which, however, doesn't impose any
> obligations on our grandchildren.
Agreed about the Provides option being temporary only and that it should
go away. As far as the debian/rules problems, I think they'll go away as
soon as most of the maintainers start messing with getting their stuff
compiled on other architectures. Honestly, right now, we're doing their
dirty work for them since we want usable and stable systems. But,
speaking for myself, I only have so much time and honestly don't feel like
trying to suggest to the x86 maintainers how things should be done to make
my platform compilation happy.
If someone really has the energy and knowledge and wants something to do
that's...uh...different, take a look at any libs package and see how
things could be fixed so as to provide near-automagic package generation
on any platform (ie, auto-detecting libc5 tools, naming of packages,
moving of files based on this info, etc). X was a nightmare for me to get
together, but luckily, the package maintainer was smart and isolated just
about every component, so eliminating the unneeded stuff was fairly easy.
Others weren't so easy, though.
I guess what I'm really bringing all of this up (deep down reason) is
because I just don't feel like working on what should be done (above
paragraph). I have tons of time, but that kinda work is just too
intensive for me right now. If we could somehow get the above solution
working and get the x86 gang to accept the change, then our "g" problems
would be solved easily....
What do you all think of that idea? Took me awhile to dig inside of
myself to figure out why I was so resistant to the "g" stuff....now I
know...
--
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: