Bug 748975 – sys-devel/crossdev should handle profiles explicitly

• Product: Portage Development
• Status: CONFIRMED ---

[Description Kent Fredric (IRC: kent\n) (RETIRED) 2020-10-14 13:46:46 UTC]

Given a tortured build process, I found through trial an error that crossdev ended up significantly delaying my ability to cross-build a chroot.

The cause?

I made the mistake of doing <tuple>-emerge @system *without* first changing my profile to the desired target.

This in turn activated this:

> profiles/embedded/package.use:sys-apps/busybox make-symlinks static
> profiles/embedded/packages:*>=sys-apps/busybox-0.60.5-r1

Which set my "/bin/sh" inside the chroot to point to "/bin/busybox"

And thereafter, I wasn't able to get anything else working, even after updating the profile, because of bug #60805

And well, make-symlinks *normally* spews this and dies, but doesn't under cross, for reasons:


>        if use make-symlinks && [[ ! ${VERY_BRAVE_OR_VERY_DUMB} == "yes" ]] && [[ ${ROOT} == "/" ]] ; then
>                ewarn "setting USE=make-symlinks and emerging to / is very dangerous."
>                ewarn "it WILL overwrite lots of system programs like: ls bash awk grep (bug 60805 for full list)."
>                ewarn "If you are creating a binary only and not merging this is probably ok."
>                ewarn "set env VERY_BRAVE_OR_VERY_DUMB=yes if this is really what you want."
>                die "silly options will destroy your system"
>        fi

Fixing *that* mess took way more time than it should have, because it broke the ability to compile Perl inside the chroot ( and the version built with cross segfaulted for some reason ), and thus autoconf was broken *and* not installable inside the chroot, and in turn, everything that uses autoconf was also broken.

I think the only way to protect against this is to require the initial crossdev "setup" to require a user specified profile token, which must exist, and have it "slotted in" at the right time in the crossdev bootstrap, so that further operations don't mess up the state for the intended purpose.

Fortunately, this means the syntax for "traditional" behaviour is not complicated, it would just be "--profile embedded" , and that could be mentioned in the "profile not specified/unknown" error message.

And that way, you wouldn't have the profile unwittingly turning on a raft of dangerous symlinks :)

[Comment 1 James Le Cuirot 2020-10-14 16:39:03 UTC]

I've never liked the embedded profile that crossdev sets up. I think few people realise you should probably change that. I don't think it's feasible to automatically select one but requiring one to be given, as you suggest, seems sensible.

[Comment 2 Sergei Trofimovich (RETIRED) 2020-10-14 18:41:23 UTC]

Yes, pre-selecting a profile is long overdue.