On Thu, Jan 5, 2017 at 11:27 PM, Kent Fredric <ken...@gentoo.org> wrote: > > If packages had a field called "BUGS=" it could contain an array of > bugs a package is known to contain, but can be conditionally avoided if > you're careful. > > Packages with non-empty BUGS= fields would be treated as hard-masked > for the purpose of repoman checks, and so packages that depend on > specific version ranges of packages with BUGS= fields are invalid, > and need their own BUGS= fields. >
So, while I'm not sure if this is the best way to go about it, I think what it does point to is there being possible benefit in creating a closer link between our repository and bug trackers. We've seen this come up in managing stable requests as well (having users be able to vote on things, having automated testing, etc). With the recent stable changes we have bugs being tagged with "atoms." With your proposal we have ebuilds being tagged with bugs. I can see benefits to having a single way to associate bugs and ebuilds, and making those associations available to bug trackers and package managers. I think the question is: 1. What is the best way to go about this? 2. Is anybody actually going to make use of this? The intended use cases in #2 probably will influence #1. However, it doesn't make sense to have multiple ways of doing these associations, because bugzilla doesn't know anything about the repo, and portage doesn't know anything about bugzilla. Having one place to store the associations and tools to make that information accessible elsewhere makes more sense. -- Rich
