From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M8sMY-0007QY-LA for garchives@archives.gentoo.org; Tue, 26 May 2009 08:50:23 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 26304E02D2; Tue, 26 May 2009 08:50:21 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id DD153E02D2 for ; Tue, 26 May 2009 08:50:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 7AA2565C12 for ; Tue, 26 May 2009 08:50:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.93 X-Spam-Level: X-Spam-Status: No, score=-2.93 required=5.5 tests=[AWL=0.669, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Kg4inWGKwS2 for ; Tue, 26 May 2009 08:50:12 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id C3042661B4 for ; Tue, 26 May 2009 08:48:30 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M8sKe-0006Sc-1v for gentoo-dev@gentoo.org; Tue, 26 May 2009 08:48:24 +0000 Received: from ip68-231-21-207.ph.ph.cox.net ([68.231.21.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 May 2009 08:48:24 +0000 Received: from 1i5t5.duncan by ip68-231-21-207.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 May 2009 08:48:24 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: better support for binary packages Date: Tue, 26 May 2009 08:48:12 +0000 (UTC) Message-ID: References: <1243245294.7098.63.camel@hspc31.informatik.uni-stuttgart.de> <1243321504.9661.14.camel@hspc30.informatik.uni-stuttgart.de> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-21-207.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 5bc979b8-5af7-4e3c-8f30-fdd6604f6536 X-Archives-Hash: e243224f69741405f01eaa404489c7d2 Philipp Riegger posted 1243321504.9661.14.camel@hspc30.informatik.uni-stuttgart.de, excerpted below, on Tue, 26 May 2009 09:05:03 +0200: > I don't see the connection between the email Fabio wrote and your > answer. Do you want to say, that you agree that he's doing what i > described and that it works the way i described it? I doubt it. If you > really care, could you answer my first email and state there the > problems you see with the approach and why you think this is making > Gentoo worse? I agree that an independent approach is the way to go. Gentoo (or=20 rather, its PMs, package managers, all three of them, of which portage is= =20 only one) doesn't do binaries really well, certainly, but I really don't=20 see that changing within Gentoo itself, except at the expense of from- source, which it does quite well indeed. > But how would you make it worse? It already has the functionality to ad= d > repositories for binpackages, why not improve it? Why leave it the way > it is? Sure, improve it, but what you are talking about isn't a simple=20 improvement, but a massive rearchitecting. That's not easily doable=20 without a chance of focus. It's that change of focus that would=20 eventually kill the quality from-source support we have and that=20 continues to develop, now. >> That said, I could envision an eselect like "binary profile" switcher, >> that subject to settings in a config file, changes USE flags, CFLAGS, >> gcc- configs an appropriate gcc version, etc, changing PKGDIR >> appropriately as well, so one could easily enough create as many >> "binary profiles" as desired and as the use case dictated. > Not sure, what the binary profile switcher really would change here. > What I was talking about were mostly USE-flags and packages, and I gues= s > your binary profile switcher doesn't change too much, there. Sure it does, but incrementally. Basically, your proposal laid out a=20 complicated tree based on metadata, a tree the package manager would have= =20 to understand and support, what I'm proposing is to allow the same thing,= =20 but not by adding all that complication to the package manager, but=20 rather, by using a newly created application to switch among the branches= =20 of that tree on request. Portage (or other PM) would use its configured=20 PKGDIR and wouldn't understand the tree, but it wouldn't need to, because= =20 the switcher would manage switching between the branches according to its= =20 configuration. The result would be that in a large enough deployment to have build- servers, the build server(s) could build a particular set of CFLAGS/USE- flags/gcc-version/arch/whatever, then switch to another branch and build=20 that set. Individual package clients could simply point at the=20 appropriate tree and get most of their packages, at least the common=20 ones, that way. Now this wouldn't directly give you the flexibility of the package name=20 changes you proposed, but it could do so indirectly, putting that=20 information in the directory tree if configured to do so. Clients may=20 need to use the binprofile switcher as well, for individual packages they= =20 chose to build outside their normal USE profile, but the process could be= =20 automated once properly configured, using PM hooks as appropriate. > It would be ok to do all this stuff in an extra project, without Gentoo= . The proposal above wouldn't be without Gentoo. It'd simply be a package=20 level thing rather than a distribution level thing. But either that or=20 the independent distribution based on Gentoo route that lxnay has taken,=20 either one works, without defocusing Gentoo on its meta-distrib-wide from= - source vision. For that matter, Gentoo already has three package managers, and binary=20 support (or the lack thereof) has been deliberately left up to the=20 package manager at this point -- it's NOT part of PMS. It'd be equally=20 possible to either take one of the current PMs and add your enhanced=20 binary package scheme to it, or to start an independent forth package=20 manager, and have it focus on binaries rather than from-source. (It=20 could even take the existing portage binpkgs and rename or otherwise=20 manage them as necessary, thereby avoiding the from-source side entirely,= =20 if so desired.) > Well, the last is a little bit impossible outside of Gentoo > (I don't want to fork the tree) and I also don't want to fork portage, > so the first is complicated, too. You mention portage, but don't mention the other PMs at all. As=20 mentioned, binary packages aren't part of PMS (the Package Management=20 Specification, the app-doc/pms package, the standard that allows PMs=20 besides portage, currently, paludis and pkgcore) at all. Gentoo really=20 doesn't have an official binary package format at all (see PMS, Appendix=20 B, Unspecified Items), only individual package managers like portage do,=20 and at present they may conflict with each other. That's both a good and a bad thing. As it's not specified, you're free=20 to define it as necessary to meet your needs for any tool you devise to=20 handle binary packages. Of course, that means that it's just that tool's= =20 definition, and at least one package manager, portage, does happen to=20 have binary packages and a working format definition for them. But that leaves you with maximum flexibility in creating whatever you=20 want, either as a separate tool (or even independent Gentoo based=20 distribution), or as an expanded PM, either forked from one of the=20 current ones, or created independently. =20 > And all this layer thing Fabio was talking about. I did not try it and = I > did not read the code, but I think it makes things much more > complicated. See also the discussion about mixing package managers > between Gentoo and Sabayon. I do not want these problems. But your proposal adds the complexity that would bring these problems,=20 whether you want them or not. Either way, the technical problems can be=20 worked thru, it's simply a matter of coding for the most part, after all,= =20 but the problems are there and must be dealt with either way. You prefer= =20 to have Gentoo do it as a whole. I say no, leave Gentoo well enough=20 alone in that regard, and let individual projects, either as Gentoo-based= =20 independent distributions, or at the application (either PM or switcher=20 level) deal with the problems. After all, Gentoo's a big organization=20 and getting all of it together addressing a problem is a VERY hard task=20 as I'm sure CiaranM among others can vouch for. A much smaller PM or=20 switcher app project is by definition of the smaller size, also much=20 easier to steer and to get things actually done in. --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman