Re: How to port to other UN*Xes? (was: Re: Inconsistent Architecture?)
William Lee Irwin III schrieb:
> On Wed, Oct 11, 2000 at 10:16:34PM +0200, Arthur Korn wrote:
> > Another hassle is the whole gcc/automake/autoconf/make/binutils
> > combo, or apache (because it really ought to be up to date). The
> > time isn't that much a problem, we have a Ultra64 for compiling
> > ... ;)
>
> It seems like gcc/automake/autoconf would actually be helpful
> in automating a number of things. What sorts of issues make it a
> hassle for you? I know that on IRIX, gcc had a bad habit of not
> working; are you encountering the same kind of problem?
None that I know of, but we are developing software here, so
users will notice if the binutils you just upgraded doesnt work
properly with that really old gcc that you are going to upgrade
next. And it's definitely more work than just let an apt-get
upgrade do it. And apt-get is something SysV packages don't have
...
> On Thu, Oct 12, 2000 at 09:10:17PM +0200, Arthur Korn wrote:
> > I think a first step would be to modify souce packages in a way
> > so one can specify a prefix at build time (default would be
> > something like /debian/$(ARCH)-$(OSNAME)$(OSREL)/
> > (thinking of automounters ...).
(thinking of this: scrap the whole $()-$()$() thingie, let the
destination be /debian/ in binary packages and everything one
desires if you compile the package yourself.)
> The build-time prefix is provided by autoconf;
But hardcoded in the source packages.
> I think hardcoded paths are pervasive despite this.
It will be definitely some work to get rid of them. In the worst
case you have to run some kind of pre-processor (sed, m4,
whatever) over the things you can't fix up otherwise. I figure
that the first packages will be hard, then we can just apply the
methods we learned about to most others, and then there will be
still some packages with spetial problems. Yes, it is non
trivial.
> Automounters usually handle the choice of what filesystem to
> mount as /usr or whatever when you have root,
I want to do this more as kind of 'package management for free
software components on a solaris system', so no, im not going to
fiddle around with /usr.
> so you don't need any defaults like that anyway, except for
> perhaps upgrading, which is probably only a few systems.
We need to descide what prefix we want to compile binary
packages for. Building packages that are relocateable at install
time would be _really_ complicated.
> Handling the fact that different machines might see the thing
> mounted in different places is another can of worms entirely.
You just have to get it into /debian or watever, or rebuild
every package yourself. But machines really ought to be set up
similarily, else it's a mess to administrate.
> On Thu, Oct 12, 2000 at 09:10:17PM +0200, Arthur Korn wrote:
> > We don't need to modify the entire distribution, only the whole
> > working environment including development tools, editors,
> > typesetters, shells and such plus the irreplaceable stuff such
> > as apache, lprng, pgsql, mysql and tools like stow, top,
> > fileutils, shellutils and some more. (Ok, it's allmost
> > everything ... ;)
>
> I'm not convinced that is the case; on the other hand, there are
> a number of things that might make this "truer":
> (1) when gcc doesn't work in an environment (try MIPS),
> everything that uses nonportable C, and that's a lot of things,
> will break trying to compile it with anything else.
Don't even try to port to such a platform (I won't). It's not
worth the hazzle. I didn't know of this problems with MIPS.
> (2) some things just aren't portable anyway, even with gcc
Then they are probably not of much use on that platform, or
there are alternatives (already in supplied by the host system).
> (3) anything that depends on /dev/, /proc/, or other kernel
> features being Linux' way will break.
So don't port them, they won't be needed. And some stuff in /dev
just has other names on other systems. The hurd gets around this
as well.
> (4) things that aren't portable across various libraries that have
> to be system supplied (X11, GL, others?) will break
X11 should not be a problem (not with solaris, we have tons of
free X11 software running on openwindows).
> (5) hardcoded paths
Make them relative where possible, and in the remaining cases a
pre processor will do on build time.
> (6) nonportable shell scripts
Policy demands /bin/sh scripts to be POSIX conformant. We might
have to take some action for /bin/bash, though there is a
/bin/bash on many solaris systems, but I don't know about 2.5.1
(the version I would like to compile for, for it to run on
everything from there to now).
> (7) things that depend on the root filesystem layout
> (/usr/bin/perl vs. /usr/local/bin/perl vs. /usr/local/perl/perl
> etc.) will break. And believe me, there aren't a whole lot of
> configure scripts that look for /usr/local/perl/perl and a lot
> of stuff really wants perl to be there very badly.
A preprocessor will do. We don't really have an alternative,
since putting symlinks outside of /debian should be avoided
wherever possible, since it would be bad if one plans to export
/debian per NFS to other machines.
> These don't look _horribly_ gruesome; despite the fact there won't be
> any real answer to some of these that will wipe out the problem across
> all packages in one fell swoop, the important things you were talking
> about probably won't be in too bad of shape, and something useful can
> be done in the way of making it work in the important cases.
I asked some admins at the LUG meeting before what they think of
the idea to manage the free software on theyer commercial UN*Xes
with apt, and they like it ...
ciao, 2ri
--
Tomorrow will be canceled due to lack of interest.
Reply to: