On Fri, 12 Nov 1999, Christos Zoulas wrote:

> On Nov 12,  2:44pm, wrstuden@nas.nasa.gov (Bill Studenmund) wrote:
> -- Subject: re: emul/aout, compat/aout [was: Re: Upcoming releases]
> 
> I prefer the idea of a separate subtree, because it is easier to clean-up.
> But it does not really matter.

What's the concensus? Is there one? Prior art?

> | I'm not sure if, given an -R/path, it should look at /path/aout first, or
> | if it should look at /path and roll over to /path/aout as above. I'd
> | suspect -R/path/aout, then /path if /path/aout doesn't exist.
> |
> | I'm not sure what to do about finding a.out libs in /path if /path/aout
> | exists..
> 
> I would just stat /path/aout and if it exists look only there. If it does
> not, then look at /path, being careful about ELF files. Also have an
> LD_WARN_AOUT option which when set to 1 warns about a.out binaries executed,
> when set to 2 warns about libraries in a non-aout directory and when set
> to 3 warns about both.

Sounds good.

> | As for two ld's, don't we have two now?
> 
> I meant having two builds for a.out

You mean an aout-still-native and an aout-after-elf versions? Hmmm.

At least a given architecture would only support one at a time..

> | Also, what about upgrading packages??
> 
> This is a complete lose. This is why the compat_aout is better in this case,
> because you can move all your packages in /emul/aout, and start from scratch.
> With compat_aout you can also have a version of the toolchain that produces
> a.out binaries coexisting with your elf one.
> 
> The major problem with packages is that you cannot live in a mixed world;
> if you upgrade parts to elf you will need to upgrade all dependent packages
> and it is a big cascading effect. Moving the libs to pkg/lib/aout can help,
> but there might be other .so files in other places [the XFree86 server
> .so files are an example]. Does perl have .so files in funny places too?

Yeah, we'll really need a way in sysinst to upgrade packages.

One of the other reasons for stiring things up now is so that we can think
about how upgrades will work with the next version, so we can do things
like packages (closer to) right.

Take care,

Bill