From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DATE_IN_PAST_12_24, DMARC_MISSING,INVALID_DATE,MAILING_LIST_MULTI autolearn=no autolearn_force=no version=4.0.0 Received: from pat.uio.no ([129.240.130.16] ident=7411) by cvs.gentoo.org with esmtp (Exim 3.30 #1) id 15JgyE-0007V2-00 for gentoo-dev@cvs.gentoo.org; Mon, 09 Jul 2001 13:45:26 -0600 Received: from sex.ifi.uio.no ([129.240.64.170]) by pat.uio.no with esmtp (Exim 2.12 #7) id 15JgxR-0003Zz-00 for gentoo-dev@cvs.gentoo.org; Mon, 9 Jul 2001 21:44:37 +0200 Received: (from terjekv@localhost) by sex.ifi.uio.no ; Mon, 9 Jul 2001 21:44:36 +0200 (MET DST) To: gentoo-dev@cvs.gentoo.org Subject: Re: [gentoo-dev] sawfish-0.38.ebuild References: <994280948.3b4385f49aa7d@www.cs.cf.ac.uk> <87ofqzu23l.fsf@codefactory.se> <3B47094F.E6A99A5F@gentoo.org> <87lmm0s56w.fsf@codefactory.se> <3B47A6A4.30651F97@gentoo.org> <3B48ADBF.7AC77EE7@gentoo.org> <20010708173019.E7526@cvs.gentoo.org> <3B49A62A.979F6D50@gentoo.org> <20010709101051.E14752@cvs.gentoo.org> X-URL: http://www.math.uio.no/~terjekv/ Organization: do you Gentoo? From: Terje Kvernes In-Reply-To: Daniel Robbins's message of "Mon, 9 Jul 2001 10:10:51 -0600" Message-ID: User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gentoo-dev-admin@cvs.gentoo.org Errors-To: gentoo-dev-admin@cvs.gentoo.org X-BeenThere: gentoo-dev@cvs.gentoo.org X-Mailman-Version: 2.0 Precedence: bulk Reply-To: gentoo-dev@cvs.gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux development list List-Unsubscribe: , List-Archive: Date: Mon Jul 9 13:46:01 2001 X-Original-Date: 09 Jul 2001 21:44:36 +0200 X-Archives-Salt: 2eccc2c1-720d-4bf3-a349-5e11c0112bfd X-Archives-Hash: c82cf96f12d6559b19f66ff227fba1ef Daniel Robbins writes: > On Mon, Jul 09, 2001 at 04:40:02PM +0200, Terje Kvernes wrote: > > > what you're basically saying is that it's up to the person making > > each build to make the choice of which lib to prioritize. > > personally, I find this rather icky, because it demands that the > > person installing the packages can't say "media(gdkpixbuf,imlib) > > and be sure that nothing ever needing just gdkpixbuf won't install > > imlib. > > The problem is that as of right now, our USE variables don't express > preference, just whether a particular extension is acceptable or > not. right, that's the problem. the question is how bad a problem it is. I have _no_ big issues with it currently, I'm just wondering if it's something that should be addressed. > There may be applications that can link to *both* gdkpixbuf and > imlib. There are really two easy solutions; and ebuild can prefer > the more advanced replacement if defined, or if there is an > either/or choice (if it's not possible to add support for both), we > can create two ebuilds: > > foo-gdkpixbuf > foo-imlib which means someone[tm] will have to maintain two different builds of what is practically the same package. it's not a very clean solution. > The either/or option doesn't seem to happen *too* often, so this > solution could work too. yeah, and as long as people keep their things up to date, sure. honestly, I'm not really worried, but it might become a case when foo has a security-issue, and the person packing it only uses foo-bar, and doesn't see foo-baz because it's not his domain. (call me paranoid, but I've had this crash on me with rpm, where the new package suddenly didn't cover all the same files because it came from another packager) > The harder third option is to increase the expressiveness of our USE > syntax, which *is* an option but I'd like to try the above solutions > first. okies. :-) > The advantage to our current approach to USE is that it's quite > straightforward. If something is in USE, the ebuild will build-in > that functionality if it can. That's easy for new users to > understand. true. then again, I really don't see how making USE express preference will manage to bite anyone. it does pretty much what you'd expect, it USEs the needed (and possible to use) packages in the given order. if both can be used, both are used. the current action isn't any more apparent, since you don't _know_ which of the packages will be used. you'll have to read the ebuild-file. I'm not familiar enough with freeBSD to know how they solve these cases. I looked a bit over the ports-documentation from the net, but didn't find anything. I'm guessing it's not a big case in reality. -- Terje