Re: [gentoo-dev] macos mess

[Jason Stubbs]

On Sunday 25 July 2004 01:54, Pieter Van den Abeele wrote:
> There are two types of Gentoo MacOS users: There is the user who wants
> to extend his Mac OS X system with packages that didn't came
> pre-installed (like tetex, kde, mysql, prolog, ,... ) Then there's the
> user who wants to use Gentoo to rebuild parts of his Mac OS X operating
> system (a new kernel, python with readline support, ...) or just build
> a Darwin system from scratch without the fancy Apple stuff.
>
> Several devs work on making Gentoo MacOS work for both users.
> Everything happens in parallel.

The real problem is that nobody (if I am like everybody else) has heard about 
this stuff except those that are following the macos movement. If you had 
announced your plan to inject everything in MacOS and keyword ebuilds on the 
assumption that those packages are available, many people could have told you 
that the issues that are happening currently would occur. More importantly, 
solutions would have been able to be created before the current issues became 
issues.

> Why does repoman/linux think the dependency graph for macos is broken?

Because it is.

> Developers that work for users of the first type, keyword packages
> against a virtual base system. The entire base system (all packages
> provided by apple) is injected into the depgraph and locked down by a
> profile. A user cannot upgrade or downgrade Apple provided stuff,
> unless the user really insists on doing so. Repoman on linux complains
> about broken macos depgraph because the macos base system obviously
> isn't injected into the depgraph under linux.

So then you are trying to use one keyword to describe both a situation where 
all base packages are available and one where they aren't?

> There are some ways to make repoman not complain about macos:

> 1. make repoman not do macos QA under linux

Ignore the issues? Not likely...

> Since repoman doesn't complain about macos under macos (it must be
> broken or somehow take into account injected packages when doing
> --emptytree), I prefer this option. It's also the least amount of work.

Does it complain when the patch Travis mentioned is in place?

> 2. make repoman macos aware

s/make repoman macos aware/include support in ALL of portage/

> This requires new portage features. Adding another file to the
> profiles, I can think of at least 2 portage feature requests that
> require adding another file to the profiles, so this can't be a short
> term solution.

Why wasn't this suggested months ago? A feature such as this (which isn't hard 
to implement btw) could allow you to not inject everything and be able 
satisfy repoman as well. It would also be useful in separating your two types 
of macos users into separate profiles.

> Opened a bug about persistent injected packages. (Also needed to make
> --emptytree work on macos, since --emptytree also removes the injected
> base system).

This is not a bug.

> 3. add empty ebuilds keyworded "-* macos" for everything that gets
> injected.
>
> Requires 300 empty ebuilds to be added for each macos profile. This is
> a hack around a portage bug that prevents a package from being purely
> virtual.

"Portage bug"? I see it as a feature that's not available yet as no one has 
ever required it or asked for it.

> There needs to be at least an empty ebuild. The problem with the workaround
> is that if a linux user uses the 'ignore keywords' syntax:
> emerge ./macos.ebuild that will break their system.

I don't think we have ever prevented users from intentionally doing something 
blatently unsupported.

> 4. change every ebuild that depends on the macos base system by making
> the base system dependencies conditional.
>
> How many ebuilds depend on 300 ebuilds? How many dependencies need to
> be changed per ebuild? What about base system evolution?

If you want to use portage as it is now with macos, these #3 and #4 are your 
*only* options without throwing QA out of the window.

Regards,
Jason Stubbs

--
gentoo-dev@g.o mailing list