On Fri, 2005-09-23 at 23:08 +0900, Jason Stubbs wrote: > *Relax!* ;) I'm quite calm, actually.
> I meant extending the fetch-restriction concept to include all cases where > an ebuild is not fully self-contained; that is, cases where the ebuild is > not capable of obtaining all necessary components to get a package to a > fully-functional state. That would be fine. I'm not sure how extending fetch restriction would do it, but I'm also not a portage developer. > Deferring discussion about it.. well, it scares me to be completely honest. > It becomes another one of those "is this going to change the requirements?" > that's always lurking. I personally don't see it as a big enough issue to sweat it. If it doesn't make it into the next portage version, we shoot for one after that. > > 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. > > Is that the only requirement? Just a boolean attribute that says the user > will have to pay money in order to make use of the package? If so, it would > seem that metadata.xml would be the perfect place, but I'll think on that > and come back to it. That is the only requirement that *I* had based on discussion with a couple users. They just wanted to know ahead of time that a package they were looking at wouldn't work without them buying it. > > > 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. > > Perhaps leave this one for another time? :) Agreed. This is best left for later. -- Chris Gianelloni Release Engineering - Strategic Lead Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
