On Wed, Feb 20, 2013 at 11:45 AM, Alec Warner <anta...@gentoo.org> wrote: > On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge <pe...@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. 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
