| 1 |
On Fri, 2005-09-23 at 23:08 +0900, Jason Stubbs wrote: |
| 2 |
> *Relax!* ;) |
| 3 |
|
| 4 |
I'm quite calm, actually. |
| 5 |
|
| 6 |
> I meant extending the fetch-restriction concept to include all cases where |
| 7 |
> an ebuild is not fully self-contained; that is, cases where the ebuild is |
| 8 |
> not capable of obtaining all necessary components to get a package to a |
| 9 |
> fully-functional state. |
| 10 |
|
| 11 |
That would be fine. I'm not sure how extending fetch restriction would |
| 12 |
do it, but I'm also not a portage developer. |
| 13 |
|
| 14 |
> Deferring discussion about it.. well, it scares me to be completely honest. |
| 15 |
> It becomes another one of those "is this going to change the requirements?" |
| 16 |
> that's always lurking. |
| 17 |
|
| 18 |
I personally don't see it as a big enough issue to sweat it. If it |
| 19 |
doesn't make it into the next portage version, we shoot for one after |
| 20 |
that. |
| 21 |
|
| 22 |
> > I think I was looking for something where a user could tell before they |
| 23 |
> > even decided to merge the package, via emerge -S or packages.gentoo.org, |
| 24 |
> > or preferably both. |
| 25 |
> |
| 26 |
> Is that the only requirement? Just a boolean attribute that says the user |
| 27 |
> will have to pay money in order to make use of the package? If so, it would |
| 28 |
> seem that metadata.xml would be the perfect place, but I'll think on that |
| 29 |
> and come back to it. |
| 30 |
|
| 31 |
That is the only requirement that *I* had based on discussion with a |
| 32 |
couple users. They just wanted to know ahead of time that a package |
| 33 |
they were looking at wouldn't work without them buying it. |
| 34 |
|
| 35 |
> > > So, if RESTRICT="fetch" were to be overloaded, there is the issue of |
| 36 |
> > > both fetch-restricted and non-fetch-restricted downloads in the one |
| 37 |
> > > package. I would think this issue exists already for some packages. How |
| 38 |
> > > is it dealt with at the moment? |
| 39 |
> > |
| 40 |
> > Currently, we just restrict the whole thing, as we have no other choice. |
| 41 |
> > On some packages, it sucks pretty badly if there's only a single |
| 42 |
> > restricted tarball and many unrestricted tarballs. |
| 43 |
> |
| 44 |
> Perhaps leave this one for another time? :) |
| 45 |
|
| 46 |
Agreed. This is best left for later. |
| 47 |
|
| 48 |
-- |
| 49 |
Chris Gianelloni |
| 50 |
Release Engineering - Strategic Lead |
| 51 |
Games - Developer |
| 52 |
Gentoo Linux |
Archives