[Exherbo-dev] Crossing over to cross

Wulf C. Krueger philantrop at exherbo.org
Tue Mar 3 10:46:45 UTC 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Saleem et al,

On 28.02.2015 19:22, Saleem Abdulrasool wrote:
> I think that its about time that we consider crossing over to
> cross.

Yes!

> In preparation for this migration, I would like to gather the set
> of things that we must do before we actually engage in merging the 
> necessary changes.

We have the todo list at http://www.exherbo.org/docs/multiarch.html.
Today, I've added the following items:

Pre-migration:
* Write proper developer docs, like e. g.
http://www.exherbo.org/docs/multibuild.html

I consider this to be *very* important (and I'm aware you'll likely
disagree about needing this pre-migration).
I've seen what happens if things just get added (e. g. the newish
python stuff) and docs are promised "soon after" - it never happens
and that's truly detrimental to the quality in Exherbo and to at least
my own motivation. (grep for WULF_IS_ANGRY in ::python or look
directly at dev-python/apsw's exheres.)

So I'm *very* *very* keen on getting proper docs. And, of course, I'm
willing to help but at the moment I don't even know where to start.

* Changing the paths in /etc/env.d/00basic and /etc/profile needs to
be done in sys-apps/skeleton-filesystem-layout
* sys-apps/skeleton-filesystem-layout can't currently be
(re-)installed in cross, e. g. edo ln -sfn "${LIBDIR}" "${ROOT}${x}"
* Get https://galileo.mailstation.de/gerrit/#/c/115 merged into
wip/cross-compiling
* Fix Paludis' tests (stripper) in wip/cross-compiling

* Merge wip/cross-compiling into Paludis' master

Well, these points should be obvious. :-)

* Prepare a new Paludis release

Telling people to use scm and downgrade later is annoying. Releases
are relatively cheap so this should be done after everything else
Paludis-related is done (bugfixes not withstanding) but pre-migration.

* Figure out what to do about the remaining stuff in several
(deprecated/obsolete) directories:

ls -l /bin /sbin /lib /lib64 /usr/bin/ /usr/lib /usr/lib64 /usr/sbin
lrwxrwxrwx 1 root root  5 Feb 28 08:03 /lib -> lib64
lrwxrwxrwx 1 root root  5 Feb 28 08:03 /usr/lib -> lib64

As I see it, we can just get rid of these two.

/bin:
total 1248
- -rwxr-xr-x 1 root root 1029496 Mar  2 22:19 bash
- -rwxr-xr-x 1 root root   32328 Mar  2 20:37 kill
- -rwxr-xr-x 1 root root   31912 Mar  2 23:20 pwd
- -rwxr-xr-x 1 root root   40072 Mar  2 23:20 readlink
- -rwxr-xr-x 1 root root   60712 Mar  2 23:20 rm
- -rwxr-xr-x 1 root root   70664 Mar  2 18:01 sed
lrwxrwxrwx 1 root root       4 Mar  2 22:19 sh -> bash

- -> /usr/${CHOST}/bin ???

/lib64:
total 140
- -rwxr-xr-x 1 root root 140944 Mar  2 18:45 ld-linux-x86-64.so.2

- -> /lib (hardcoded in the Linux kernel, IIRC,right?)

/sbin:
total 864
- -rwxr-xr-x 1 root root 882840 Mar  2 18:45 ldconfig

- -> /usr/${CHOST}/bin (yes, bin)

/usr/bin/:
total 72
- -rwxr-xr-x 1 root root 27880 Mar  2 23:20 env
lrwxrwxrwx 1 root root    29 Mar  2 23:21 m4 ->
../x86_64-pc-linux-gnu/bin/m4
- -rwxr-xr-x 1 root root 40072 Mar  2 23:20 readlink

- -> /usr/${CHOST}/bin ???

/usr/lib64:
total 0
drwxr-xr-x 1 root root 6 Mar  2 23:41 debug

Will be solved by the pending Paludis patch.

/usr/lib64/locale/locale-archive <--- can simply be nuked.

/usr/sbin:
total 0

Nuke it.

We should get completely rid of the sbin/bin split. Let's just use bin
and be done with it. The split is archaic nonsense that should have
been abolished at least a decade ago.

The above directory stuff needs to be done before the migration in
order to avoid later messy chaos.


Post-migration:

* Implement multiple cross compilation hosts/targets:

Details are in the document.



Furthermore, we now have several places we're gathering stuff at -
this very mailinglist, the bugtracker and our IRC logs. :-)

Since the remaining issues are mostly well-defined tasks, I'd like to
suggest using our Bugzilla to track everything.
E. g. filing a tracker bug for The Great Merge (Take Two) and several
blocking bugs for the different tasks themselves. I'll gladly do that
if we can agree on handling things like this.

What do you say?

- -- 
Best regards, Wulf

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlT1kRQACgkQnuVXRcSi+5omhgCdGJ+4QEMyxV7mHpq4be2Zegpq
jysAnRPthIvxirXJDeHXZn/nlrLOPU/L
=VC0G
-----END PGP SIGNATURE-----



More information about the Exherbo-dev mailing list