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="purchase" or somesuch parallel to > RESTRICT="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. Also, my proposal was based on several user requests to *have* some kind of information showing that the package requires a purchase/license. 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. The only way I could see a restriction being useful is if we also added a FEATURE to go along with it. FEATURE="non-commercial" RESTRICT="commercial" (in ebuild) emerge doom3 Calculating dependencies !!! All ebuilds that could satisfy "doom3" have been masked. !!! One of the following masked packages is required to complete your request: - games-fps/doom3-1.3.1302 (masked by commericial status) ...or some such thing. Even this wouldn't give the user any idea of the status of the package until emerge time, even with a pretend. I think I was looking for something where a user could tell before they even decided to merge the package, via emerge -S or packages.gentoo.org, or preferably both. > Overloading RESTRICT="fetch" to include this case seems like the best method > to me. Really, what's the difference between fetch-restricted and "purchase > -restricted"? From a portage point of view, they both require the user to > dance through some hoops before getting access and there's not really any > important difference beyond that. On the contrary, as I stated above, there's some differences. I'll give another example, Neverwinter Nights. You can install Neverwinter Nights without using *any* media and using only freely-downloadable tarballs. To *play* the game, however, you need a CD key. A fetch restriction here wouldn't help the user in any way determine that they are going to need a CD key. All it would do is force them to jump through hoops to download 1.5GB+ of data, only to install it and find out that they can't use the game anyway without a purchase. > So, if RESTRICT="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. -- Chris Gianelloni Release Engineering - Strategic Lead Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
