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 1N6gfa-0001nl-LP for garchives@archives.gentoo.org; Sat, 07 Nov 2009 08:29:14 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 03658E082B; Sat, 7 Nov 2009 08:29:13 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id AA3AFE082B for ; Sat, 7 Nov 2009 08:29:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 296B267C06 for ; Sat, 7 Nov 2009 08:29:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 required=5.5 tests=[AWL=0.049, BAYES_00=-2.599] 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 ObgSKUw5Bj7O for ; Sat, 7 Nov 2009 08:29:05 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id EE7E2676DF for ; Sat, 7 Nov 2009 08:29:04 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1N6gfF-0001SN-8I for gentoo-dev@gentoo.org; Sat, 07 Nov 2009 09:28:53 +0100 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 ; Sat, 07 Nov 2009 09:28:53 +0100 Received: from 1i5t5.duncan by ip68-231-21-207.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Nov 2009 09:28:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: redistribute intel rpms Date: Sat, 7 Nov 2009 08:28:30 +0000 (UTC) Message-ID: References: <20091106160441.251e1304@canfar.phys.uvic.ca> 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: 59bf4710-3d0f-4e4b-a912-b739225cf738 X-Archives-Hash: 3be43478e0cf4a99ed333c0c6b95c44d S=C3=A9bastien Fabbro posted on Fri, 06 Nov 2009 16:04:41 -0800 as excerp= ted: > We have a few fetch restricted Intel packages in the main tree (icc, > ifc, mkl, ipp, tbb). All except tbb are closed-source but free with > non-commercial licenses. Lately upstream has repackaged the icc and > ifort (ifc) as a big tar blob containing all of them, but also release > some of them separately. For various reasons we would like to keep > separate ebuilds. The problem is the separate packages have common > libraries, causing duplication and file collisions. So the idea was to > download the tar blob which contain a few binary rpms and base new > ebuilds on these rpms. To here looks reasonable... > This means we will have to re-distribute the rpms on our mirrors. This conclusion doesn't necessarily follow from the above, unless you=20 summarized-out the important technical issues. See below. > I can't understand from the many licenses if we are > allowed to do it, it surprisingly looks like we can do it. No position on the legal aspect, except that if we can avoid the question= =20 by not distributing them at all, much as we do with various other=20 restrict=3Dmirror packages, that would seem to me to be the way to go. What I'm missing is why a combination of the approach used for, say, the=20 kde split ebuilds, and the standard restrict=3Dmirror ebuilds, can't be=20 used. It seems to me that the ebuilds could each require the big combo- tarball, extract only the necessary component rpms, and go from there,=20 much as the kde split ebuilds do with the big combo tarballs that kde=20 ships except they don't have the rpms step to worry about and I expect=20 the kde interdependencies were far more complex to try to work out (you'd= =20 need to ask the gentoo/kde folks on that to be sure, but from a user who=20 followed the experimentals to some degree, that certainly seems to be the= =20 case). The big combo tarball could then be restrict=3Dmirror or whatever, with o= r=20 without a specific user click-thru (and restrict=3Dinteractive or whateve= r)=20 as necessary and already used on some packages, following existing=20 policies. Of course, there's certainly the complexity of automating the tarball=20 unpack of only the specific needed components, but gentoo/kde has a=20 **LOT** of experience with that sort of thing by now, and I'm sure they'd= =20 be happy to share hints and helpful tactical strategies with you, if you=20 ask, and there's no way I can conceive it being even half as dependency=20 convoluted as kde4 was to figure out, so it should be FAR easier. --=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