Re: [gentoo-dev] Re: linux-firmware

[Alec Warner <antarus@gentoo.org>]

On Wed, Feb 20, 2013 at 9:17 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Feb 20, 2013 at 11:45 AM, Alec Warner <antarus@gentoo.org> wrote:
>> On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge <peter@stuge.se> wrote:
>>>
>>> It makes no sense to make that unneccessarily difficult for users.
>>
>> I don't think fetch restriction is that annoying. You could argue that
>> we do it debian / ubuntu style where the files are fetched in a
>> postinstall, but I think that is sort of hacky myself.
>
> The concern wasn't with fetch restrictions so much as with masking.
> Fetch restriction works if upstream provides a tarball but we can't
> redistribute it.  If upstream doesn't provide a tarball and we can't
> redistribute anything, then a live scm ebuild is the only way to
> deploy something, and current policy is that these must be masked.

Not following you here. We cannot redistribute dev-java/sun-j2ee for
instance. We don't mirror dev-java/sun-j2ee. We tell the user 'hey go
download j2ee from Oracle and put it in $LOCATION. A live SCM ebuild
is not the only way to deploy something. If the user has to go
download a blob out of linux-firmware's gitweb because we feel we
cannot legally distribute the firmware, then that is what they have to
do. If the user has to go to the manufacturers website to get the
firmware, then that is what they have to do.

>
> I do understand Diego's concerns with some edge cases, including the
> tinderbox.  Some kind of PROPERTIES=network solution might be the best
> compromise.  Until then masking things is better than dropping them.
> It just doesn't seem ideal to have packages that are basically
> permanently masked.  Masking is usually a temporary solution for
> testing or removal, or it can be applied to things like live ebuilds
> which are moving targets that can never have QA.  I think the fact
> that we have to resort to masking in this case is more a reflection of
> a limitation of portage, but saying so doesn't fix anything, so we'll
> just have to live with it for now...
>
> Since this topic came up elsewhere in the thread it really isn't my
> goal to cause inconvenience or debate things imply for their own sake.
>  I just would like to see things improve when it is possible, and
> don't tend to censor my questions as a result.  I don't really
> disagree with the status quo simply because it is the status quo.  I
> think that is more selection bias - when I agree with the status quo
> I'm less likely to post anything at all...
>
> Rich
>