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

[Chris Gianelloni <wolf31o2@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]