Mailing List Archive

x86-fbsd keyword in main tree?
Okay, solar asked me yesterday, and I think this might be the good moment to
start this out.
Right now the x86-fbsd keyword is not being used in the main tree, and the
whole Gentoo/FreeBSD is handled in an overlay, sharing the ~x86 keyword with
standard Gentoo/Linux.
Unfortunately this has a series of drawbacks:

- we need to package.mask packages that could just not have ~x86-fbsd keyword
at all (because being linux specifics);
- we can see the last working version of a package go away because later
versions are ~x86 and they don't work for us (old flex might have been an
example but that's now fixed; findutils can be another example);
- we cannot make sure that the deptree is satisfied.

To bring ~x86-fbsd keywording in main tree, we mainly need to move a true
profile in the tree, not a dummy one, mark it as indev and start the
keywording. (I've already cleaned up the default-bsd/fbsd profile so that it
does work with the current base/ profile.
As long as virtual/libc is not in the dependencies, it shouldn't trigger any
kind of problems to leave the sys-freebsd category in the overlay, if we
really need to start needing that, I'll see to make the ebuild quality level.

It's not going to be a quick thing, as I'm mostly alone with Gentoo/FreeBSD
right now (help is always welcome), but times are mature so that I can
provide a decent experience to users.

Can anybody name a showstopper to this?

--
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
Re: x86-fbsd keyword in main tree? [ In reply to ]
Diego 'Flameeyes' Pettenò wrote:
> Okay, solar asked me yesterday, and I think this might be the good moment to
> start this out.
> Right now the x86-fbsd keyword is not being used in the main tree, and the
> whole Gentoo/FreeBSD is handled in an overlay, sharing the ~x86 keyword with
> standard Gentoo/Linux.
> Unfortunately this has a series of drawbacks:
>
> - we need to package.mask packages that could just not have ~x86-fbsd keyword
> at all (because being linux specifics);
> - we can see the last working version of a package go away because later
> versions are ~x86 and they don't work for us (old flex might have been an
> example but that's now fixed; findutils can be another example);
> - we cannot make sure that the deptree is satisfied.
>
> To bring ~x86-fbsd keywording in main tree, we mainly need to move a true
> profile in the tree, not a dummy one, mark it as indev and start the
> keywording. (I've already cleaned up the default-bsd/fbsd profile so that it
> does work with the current base/ profile.
> As long as virtual/libc is not in the dependencies, it shouldn't trigger any
> kind of problems to leave the sys-freebsd category in the overlay, if we
> really need to start needing that, I'll see to make the ebuild quality level.
>
> It's not going to be a quick thing, as I'm mostly alone with Gentoo/FreeBSD
> right now (help is always welcome), but times are mature so that I can
> provide a decent experience to users.
>
> Can anybody name a showstopper to this?
>

Yes, x86-fbsd is not a 'working'[1] profile keyword.

[1]The same reason why ppc-macos has some weird and potentially
dangerous profile tricks to keep their systems running. We are looking
at adding PROFILE_ARCH, or use.force to the profiles to remedy the
situation. Basically portage expands $ARCH into use ( so x86-fbsd has
ARCH x86, and would get "x86" in use, which IMHO, isn't that horrible ).
However, you also don't get x86-fbsd shoved into USE, so you have to
inject it elsewhere, and then users could do something stupid like
-x86-fbsd in make.conf, and unset their ARCH flag = bad.

PROFILE_ARCH='x86-fbsd' -> would get forcefully injected into USE, OR
use.force: x86-fbsd -> a use flag that isn't killed by -*.

Whatever the fix is we should be able to make a 2.0.54-r1 release with
it, still need to talk to Zac, if anyone has any comments on this, now
would be the time ;)

-Alec Warner
Re: x86-fbsd keyword in main tree? [ In reply to ]
On Thu, 09 Mar 2006 10:20:33 -0500
Alec Warner <antarus@gentoo.org> wrote:

> Basically portage expands $ARCH into use ( so
> x86-fbsd has ARCH x86, and would get "x86" in use, which IMHO, isn't
> that horrible ). However, you also don't get x86-fbsd shoved into
> USE, so you have to inject it elsewhere, and then users could do
> something stupid like -x86-fbsd in make.conf, and unset their ARCH
> flag = bad.

The profiles currently in the overlay set ARCH=x86-fbsd. Whether that's
right or not is another debate, but it invalidates that particular
problem.
--
gentoo-dev@gentoo.org mailing list
Re: x86-fbsd keyword in main tree? [ In reply to ]
On Thursday 09 March 2006 16:20, Alec Warner wrote:
> Basically portage expands $ARCH into use ( so x86-fbsd has
> ARCH x86, and would get "x86" in use, which IMHO, isn't that horrible ).
Right now ARCH=x86-fbsd for G/FBSD, as spb already said, so it's not much of
the problem.
If that will change, it will with GLEP47 anyway, so that's not either a
particular problem.

> Whatever the fix is we should be able to make a 2.0.54-r1 release with
> it, still need to talk to Zac, if anyone has any comments on this, now
> would be the time ;)
Not like we're going to use 2.0.54 as it's mostly broken for Gentoo/FreeBSD...
right now we need 2.1, and there will probably be more things to fix in the
future, so...

--
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
Re: x86-fbsd keyword in main tree? [ In reply to ]
On Thu, 9 Mar 2006 15:29:23 +0100
"Diego 'Flameeyes' Pettenò" <flameeyes@gentoo.org> wrote:

> To bring ~x86-fbsd keywording in main tree, we mainly need to move a
> true profile in the tree, not a dummy one, mark it as indev and start
> the keywording. (I've already cleaned up the default-bsd/fbsd profile
> so that it does work with the current base/ profile.
> As long as virtual/libc is not in the dependencies, it shouldn't
> trigger any kind of problems to leave the sys-freebsd category in the
> overlay, if we really need to start needing that, I'll see to make
> the ebuild quality level.

My main objection here is "If it's worth doing, it's worth doing
properly." I'd rather see the keywords and system ebuilds merged at the
same time, so we don't end up with some half-system that has keywords
in the tree but can't be installed.

> It's not going to be a quick thing, as I'm mostly alone with
> Gentoo/FreeBSD right now (help is always welcome), but times are
> mature so that I can provide a decent experience to users.
>
> Can anybody name a showstopper to this?

As far as I'm concerned the main reason this has been almost exclusively
in overlay for so long is that we can rework things much more easily
without worrying about breaking backwards compatibility or upgrade
paths. If it's in a state where that's not likely to be an issue any
more then I'd be in favour of merging it, as long it's done right. That
in itself will of course be a non-trivial task, but I can awake from my
BSD-related hibernation to get it done if it's reckoned to be a good
idea and unlikely to break anything.

On the other hand, I don't want to do this if there are serious
objections from other devs, so any opinions from outside gentoo-alt are
welcome.
--
gentoo-dev@gentoo.org mailing list
Re: x86-fbsd keyword in main tree? [ In reply to ]
Stephen Bennett wrote:
> On Thu, 09 Mar 2006 10:20:33 -0500
> Alec Warner <antarus@gentoo.org> wrote:
>
>
>>Basically portage expands $ARCH into use ( so
>>x86-fbsd has ARCH x86, and would get "x86" in use, which IMHO, isn't
>>that horrible ). However, you also don't get x86-fbsd shoved into
>>USE, so you have to inject it elsewhere, and then users could do
>>something stupid like -x86-fbsd in make.conf, and unset their ARCH
>>flag = bad.
>
>
> The profiles currently in the overlay set ARCH=x86-fbsd. Whether that's
> right or not is another debate, but it invalidates that particular
> problem.

The problem being that your ARCH (architecture) IS x86, just as
ppc-macos's architecture is ppc, and there may be patches that apply to
both sets equally, and conversely things that apply to only linux.

Now if GLEP47 is approved, then the point is moot ( x86 implies
x86-linux, or whatever the corresponding keyword is ).

If this is the tract we are going to head in I need to change the docs
to reflect what ARCH really means.

At present in man portage:
ARCH Architecture type (x86/ppc/hppa/etc...).
PROFILE_ARCH
Distinguish machines classes that have the same ARCH. All
sparc machines have ARCH=sparc but set this to either 'sparc32'
or 'sparc64'.

Ciaran had suggested pushing PROFILE_ARCH into USE, although that
implies that x86? = ARCH x86 and not necessarily 'x86-linux' since
anything running on x86 would have ARCH=x86.

While I think the above is the 'proper' way to do things, it would
require a massive migration of ebuilds in the tree, and no one has
volunteered for that task, as well as making sure anything that uses
'x86' in this case runs on everything running on x86..it becomes quite
complicated, even if it is the most flexable.

Regardless, I'd like to reach a conclusion about this, was GLEP 47
submitted to the council for the next meeting?

-Alec Warner

--
gentoo-dev@gentoo.org mailing list
Re: x86-fbsd keyword in main tree? [ In reply to ]
On 09-03-2006 12:30:33 -0500, Alec Warner wrote:
> Regardless, I'd like to reach a conclusion about this, was GLEP 47
> submitted to the council for the next meeting?

As far as I know: no. I didn't myself because I'm having a problem with
ppc-macos and the upcoming x86-macos (they will probably have a lot in
common) and am not completely sure whether what Diego and I proposed is
actually flexible enough.


--
Fabian Groffen
--
gentoo-dev@gentoo.org mailing list
Re: x86-fbsd keyword in main tree? [ In reply to ]
On Thursday 09 March 2006 20:37, Grobian wrote:
> As far as I know: no.  I didn't myself because I'm having a problem with
> ppc-macos and the upcoming x86-macos (they will probably have a lot in
> common) and am not completely sure whether what Diego and I proposed is
> actually flexible enough.
I don't think we have problem with flexibility, but rather with phrasing, as
it's still blocked down to that point.
Of course, it would help if someone from portage team would like to work on
its implementation beforehand so that we can experiment the flexibility :P

--
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE