From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ms-smtp-04.texas.rr.com (ms-smtp-04.texas.rr.com [24.93.47.43]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j47FVnrT012674 for ; Sat, 7 May 2005 15:31:49 GMT Received: from [192.168.0.101] (cpe-24-27-15-220.austin.res.rr.com [24.27.15.220]) by ms-smtp-04.texas.rr.com (8.12.10/8.12.7) with ESMTP id j47FVogJ016520 for ; Sat, 7 May 2005 10:31:54 -0500 (CDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <20050507154950.1ccd0596@snowdrop> References: <42761B77.4030206@salomon.at> <20050502151356.6d9ca385@snowdrop> <20050503000229.GA10998@exodus.wit.org> <20050503151220.076cc62f@snowdrop> <20050505084849.GC13705@exodus.wit.org> <20050505150105.7fc5f5de@snowdrop> <20050506050958.GH13705@exodus.wit.org> <20050506142849.2aefb952@snowdrop> <20050507010518.GO13705@exodus.wit.org> <20050507023920.0d9d27a3@snowdrop> <20050507070817.GA12172@exodus.wit.org> <20050507154950.1ccd0596@snowdrop> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <496a69ca1beb83ff3b5ee29ed055ba7c@gentoo.org> Content-Transfer-Encoding: 7bit From: Kito Subject: Re: [gentoo-dev] new glep draft: Portage as a secondary package manager Date: Sat, 7 May 2005 10:31:49 -0500 To: gentoo-dev@lists.gentoo.org X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.622) X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Archives-Salt: ca74651a-704b-4d7c-9e73-0aa94bc00a76 X-Archives-Hash: 6764c71e336e35e2794dbfdc685d97cb -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 7, 2005, at 9:49 AM, Ciaran McCreesh wrote: > On Sat, 7 May 2005 02:08:17 -0500 Brian Harring > wrote: > | Re: changes, yes, things will need changes, and again, as stated > | thrice, those who want the changes are the ones who are stuck doing > | said changes. In other words, the actual work required to > | cleanse/correct the tree isn't getting dumped on ebuild devs as a > | whole. > > Isn't going to work. A lot of these changes need package-specific > knowledge that most people just don't have. If a dev doesn't have adequate knowledge for a particular package he shouldn't be fscking with it in the first place. So there said package can sit, having only the ability to install to / just like it always has until someone with interest/need/knowledge comes along and takes care of it. All the points you are making sound like the result of too much crisis management, progress shouldn't be impeded by fear of work or change. > > | In other words, you would be wise to snipe the suggested changes to > | writing an ebuild, rather then dragging out example after example of > | possible required changes to the tree. The examples you're dragging > | out basically come down to making sure the ebuild is 'correct' for > the > | package. I can just as quickly drag out example after example of > | potential mistakes ebuild devs can make _now_. > > No, they're a demonstration of why the GLEP in its current form is > inadequate. I'll carry on pulling up further examples until you realise > that it's not just a minor issue, it's a huge problem that needs a big > change to the GLEP. How about suggesting what that big change would be? > > | Remember that gleps go through several rounds of > | discussion, I'd like to see this round keep moving rather then get > | stuck in the mud. > > The reason that this thing was written up as a GLEP was because the > author was trying to bypass the discussion and get around having to fix > various flaws that had been pointed out previously. > > | Could you break it down to "if I'm going into home, I need xyz at the > | home level rather then global/usr" ? > > Hrm. Being able to say "I need xyz installed globally, and abc > installed > either globally or at home level" would work if and only if there was a > way of finding out where abc and xyz had been installed. Hmmm, what about a possible extension to the world file or a create a new file to store metadata such as the package installation prefix. Kito -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) iD8DBQFCfN9mJ0rMK/3OwgsRAkQ4AJsFdsnck7jScHUDjarT3zO/+f0aCgCdGxyR O8+F1FVJNGQSAO5peV9/qhk= =4kQf -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list