From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15051 invoked from network); 25 Jul 2004 01:23:19 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 25 Jul 2004 01:23:19 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BoXjS-0006Jp-Lx for arch-gentoo-dev@lists.gentoo.org; Sun, 25 Jul 2004 01:23:18 +0000 Received: (qmail 6011 invoked by uid 89); 25 Jul 2004 01:23:18 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 27976 invoked from network); 25 Jul 2004 01:23:17 +0000 From: Jason Stubbs To: gentoo-dev@lists.gentoo.org Date: Sun, 25 Jul 2004 10:26:28 +0900 User-Agent: KMail/1.6.82 References: <0FD0031C-DD92-11D8-B5A6-000D93283962@gentoo.org> In-Reply-To: <0FD0031C-DD92-11D8-B5A6-000D93283962@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200407251026.28675.jstubbs@gentoo.org> Subject: Re: [gentoo-dev] macos mess X-Archives-Salt: de470977-fb92-4fe9-bf5d-ba095ca51210 X-Archives-Hash: 472306f6ea5744332adc708c80cfdc43 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@gentoo.org mailing list