On 09/07/2014 09:03 PM, Rich Freeman wrote: > Right now the general policy is that we don't allow unmasked (hard or > via keywords) ebuilds in the tree if they use an scm to fetch their > sources. There are a bunch of reasons for this, and for the most part > they make sense.
Hard masking is a relic from the days that we didn't just have empty keywords, most of the VCS ebuilds in the tree just have empty keywords now and are not actually hard masked. I'd say if you set ACCEPT_KEYWORDS="**" then you get to keep the pieces. > > I was wondering if this policy still made sense in the case of scm > ebuilds that pull a particular git commit. While portage can't check > the Manifest, the fact is that git will in this case, and since we're > pointed at a content-hashed commit we can ensure that the package > never changes. We of course can't mirror it with the current setup > (there is no real reason we couldn't mirror git, but this is a > different problem). > > Tying ebuilds to a git commit has pros and cons, but I'm hard-pressed > to think of any actual QA issues. That is, something that would make > our tree inconsistent, or create a security vulnerability. Just use a snapshot tarball, it's not hard to do, it allows us to mirror the file, checksum the file, and users can reinstall while offline if they have fetched ones. > > Am I just not thinking of something? It would probably be most useful > for packages that track a backport branch or something along those > lines - where upstream does not regularly update their tarballs so > we're constant creating patchsets. In this case all we'd have to do > is bump the commit ID in the ebuild. > I make a lot of VCS snapshot tarballs, it's annoying, but the benefits to the users seem to far outweigh the 2-3 minutes of aggravation it takes me to make a tarball. -Zero > -- > Rich > >
signature.asc
Description: OpenPGP digital signature
