Re: [gentoo-dev] "Commercial" software in portage

[Jason Stubbs]

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="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.

*Relax!* ;)

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.

> 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. 
It becomes another one of those "is this going to change the requirements?" 
that's always lurking.

> 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.

> > 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? :)

-- 
Jason Stubbs