From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7282 invoked from network); 25 Jul 2004 04:38:58 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 25 Jul 2004 04:38:58 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1Boamm-0007q8-Nq for arch-gentoo-dev@lists.gentoo.org; Sun, 25 Jul 2004 04:38:56 +0000 Received: (qmail 24997 invoked by uid 89); 25 Jul 2004 04:38:56 +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 30507 invoked from network); 25 Jul 2004 04:38:56 +0000 From: Jason Stubbs To: gentoo-dev@lists.gentoo.org Date: Sun, 25 Jul 2004 13:42:09 +0900 User-Agent: KMail/1.6.82 References: <200407251150.50056.jstubbs@gentoo.org> <180D5EB6-DDEC-11D8-B5A6-000D93283962@gentoo.org> In-Reply-To: <180D5EB6-DDEC-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: <200407251342.09843.jstubbs@gentoo.org> Subject: Re: [gentoo-dev] macos mess X-Archives-Salt: 7ea7f8bf-4df5-4f39-9d88-03a8f5e2306c X-Archives-Hash: 4efe537f4302741b585f57375390127b On Sunday 25 July 2004 12:38, Pieter Van den Abeele wrote: > It's a glep. The pathspec glep. > http://www.gentoo.org/proj/en/gentoo-alt/macos-1.xml "It covers all known relevant areas except cross-platform dependency coherency issues." These are the issues that are happening now due to jumping the gun. > I can forward all email I have about to you if you like. Might be > interesting to read it and get a better idea about it. No, thanks. Just get the implementation details of the aforementioned glep completed, get the glep approved and I give you my word that it'll be imlemented. > >> It's a relatively simple feature compared to the other requirements I > >> have for a next generation portage. > > > > So you're planning to fork the project? > > No I'm not. An experimental prototype yes. > Anyway, keep tuned. "Next generation portage" implies throwing away the current portage. If it's an experimentatl prototype to help with the current portage, do you have a roadmap on how it is to be integrated? How about a list of features? I can guarantee you that I am personally working on some of them and so we have needless duplication of effort. If your work is truly intended to benefit the current portage, why is it so closed? > >> What MacOS is doing right now is moving forward and identifying all > >> MacOS related issues, creating bug reports for them and we try to do our > >> best finding both long term and short term solutions. We can't afford to > >> be put on hold for another year, unfortunately. > > > > I've been an official developer for just over five months, and have > > been working on portage and hanging out in #gentoo-portage and on the > > gentoo-portage-dev list for about nine months yet I haven't heard any > > discussion whatsoever about what is required to support portage on > > macos. THAT is what has held it up for a year. > > Oh well, macos is here now. Let's start doing things now. Whether or > not you heard about it before is not really relevant anymore. Most of > the stuff is happening now. It is completely relevant. Without any advance warning, you have succeeded at tripling the pressure on myself and other members of the portage team to get things done "now". If you had have spoken up to the relevant projects about possible impact, we all could have prepared for it before this "now" ever happened. I don't know why I (or anybody else) should have to clean up after you, but I'll get to work on throwing --inject away completely and replacing it with an profile addition (which will be user extendable) that will allow the ignoring of certain packages during dep resolution. > I've been wanting to throw that pathspec thing away and start all over > again, cause I wrote a comment on it anyway. (I wasn't really > flattering about the ugly code at the bottom of the glep. I dislike > nested ifs.). This is a QA nightmare. You have this release out there that none of the supporting projects were ready for and it sounds like you aren't even sure about how to support it yourself. A "deal with it as it happens" approach is simply not going to cut it. > > Yes, repoman is quite buggy. That is no reason to use it as a > > scapegoat. > > I've written a patch for it. I think others have been more verbose > about repoman in this thread. Have nothing against it. I can guarantee that patch wont be included. To borrow Nick's words, "I really dislike special cases." > >>>> 2. make repoman macos aware > >>> > >>> s/make repoman macos aware/include support in ALL of portage/ > >> > >> That's the plan. There will be code, no worry. But until there's code, > >> we use the cleanest possible short-term solution for various issues. > > > > Again, by forking? > > no. We do currently maintain a small patchset to make portage work > under osx. We are working on making that patchset clean and will submit > it to you guys in different reviewed bits and pieces. This, too, should have been done before any release was made. > >> When I openened the bug about persistent packages, somebody masked it > >> as a DUP for a bug numbered somewhere between 11000 - 12000 (we're at > >> 54000 right now). I'm assuming similar feature requests have been > >> waiting for some time. > > > > Please give bug numbers. I want the facts first-hand. > > My bug was marked as a dup for > http://bugs.gentoo.org/show_bug.cgi?id=11697 I can't check it now as bugs is down, but I hope that the profile addition I mentioned above will solve it. Regards, Jason Stubbs -- gentoo-dev@gentoo.org mailing list