From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1EIoGX-0006hU-OR for garchives@archives.gentoo.org; Fri, 23 Sep 2005 14:11:06 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id j8NE46Xt009050; Fri, 23 Sep 2005 14:04:06 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id j8NE1oQs018299 for ; Fri, 23 Sep 2005 14:01:50 GMT Received: from zh034158.ppp.dion.ne.jp ([222.3.34.158] helo=opteron246.suzuki-stubbs.home) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1EIoDh-0005OQ-Cz for gentoo-dev@lists.gentoo.org; Fri, 23 Sep 2005 14:08:09 +0000 Received: by opteron246.suzuki-stubbs.home (Postfix, from userid 1000) id 388C4103D3D; Fri, 23 Sep 2005 23:08:11 +0900 (JST) From: Jason Stubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] "Commercial" software in portage Date: Fri, 23 Sep 2005 23:08:08 +0900 User-Agent: KMail/1.8.91 References: <20050921172801.42BBEF5C20@mail.deploylinux.net> <200509231038.17738.jstubbs@gentoo.org> <1127482090.24269.133.camel@cgianelloni.nuvox.net> In-Reply-To: <1127482090.24269.133.camel@cgianelloni.nuvox.net> 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 Content-Type: multipart/signed; boundary="nextPart2274378.PChyOeF1U1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509232308.10865.jstubbs@gentoo.org> X-Archives-Salt: aaa0a2e5-d3bc-4ad3-9c98-cbcf9a703d85 X-Archives-Hash: 35d227c6194e7672c498b5b156bcf8a8 --nextPart2274378.PChyOeF1U1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 23 September 2005 22:28, Chris Gianelloni wrote: > On Fri, 2005-09-23 at 10:38 +0900, Jason Stubbs wrote: > > On Friday 23 September 2005 06:09, Chris Gianelloni wrote: > > > it would be a good idea to give the user some way of knowing that a > > > package requires some additional purchased (or otherwise obtained) > > > portion that is not a distfile/tarball. > > > > It would be a good idea, indeed. RESTRICT=3D"purchase" or somesuch > > parallel to RESTRICT=3D"fetch" would solve this just as well. However, > > whenever adding new stuff like this, as a portage developer, I always > > ask what use of it can be made by portage? I can't see anything other > > than passing the information to a user interface to blink some text at > > the user... > > The problem stems from a fetch restriction (of any kind) not being > sufficient to be this marker. Take my classic doom3 example. There is > *nothing* restricted, download-wise. It just requires you have the data > files available, either via a CD, or copied to disk somewhere. It > *also* requires a CD key. I don't see where any kind of fetch > restriction-like device would accommodate this, as the restrictions are > on installation/execution, not on fetching. *Relax!* ;) I meant extending the fetch-restriction concept to include all cases where= =20 an ebuild is not fully self-contained; that is, cases where the ebuild is=20 not capable of obtaining all necessary components to get a package to a=20 fully-functional state. > Also, my proposal was based on several user requests to *have* some kind > of information showing that the package requires a purchase/license. This, I understood. > Since it seems that many are confusing this with the nature of the > package (check out the sun-jdk question), it leads me to believe that > this is best left alone and to simply wait for GLEP23 to be wide-spread, > then to revisit this, since LICENSE definitely isn't the place for it, > and neither is any kind of RESTRICT, as far as I can tell. Deferring discussion about it.. well, it scares me to be completely honest.= =20 It becomes another one of those "is this going to change the requirements?"= =20 that's always lurking. > I think I was looking for something where a user could tell before they=20 > even decided to merge the package, via emerge -S or packages.gentoo.org,= =20 > or preferably both. Is that the only requirement? Just a boolean attribute that says the user=20 will have to pay money in order to make use of the package? If so, it would= =20 seem that metadata.xml would be the perfect place, but I'll think on that=20 and come back to it. > > So, if RESTRICT=3D"fetch" were to be overloaded, there is the issue of > > both fetch-restricted and non-fetch-restricted downloads in the one > > package. I would think this issue exists already for some packages. How > > is it dealt with at the moment? > > Currently, we just restrict the whole thing, as we have no other choice. > On some packages, it sucks pretty badly if there's only a single > restricted tarball and many unrestricted tarballs. Perhaps leave this one for another time? :) =2D-=20 Jason Stubbs --nextPart2274378.PChyOeF1U1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBDNAxKxvWNPsk/ZP4RAtDCAKCwo13BfzIpmjUeABslgCqnlf/F5ACeIWGx G+85MyJbxXBDkLvDxwp7t2s= =2HRS -----END PGP SIGNATURE----- --nextPart2274378.PChyOeF1U1-- -- gentoo-dev@gentoo.org mailing list