On Fri, May 16, 2014 at 6:10 PM, Karanbir Singh <mail-lists at karan.org> wrote: > > Packaging is hard, sure - and it gets dramatically harder when executing > without a policy framework. The includepkg / exclude process is also not > easy, neither is the costs nor priorities, they all come with their own > wins and pains. > > Also worth noting is that SIG's dont map to repos - many ( most so far ) > are likely going to opt to deliver into a common set of repos, making it > easier for others to consume components, specially the infra level SIGs > like Virt / Storage etc. So we need to address this issue either way, > sooner the better I've always thought that package lists should be the thing with ultimate control. That is, a package list should be able to specify both the repo and version for every package that should be installed. That would mean a SIG just has to publish a list of packages and add anything unique to _some_ repo. Anyone consuming such a list would be assured that they were only using packages that had previously been installed and tested together. You'd need some changes to yum to respect the repo specification (which would avoid a lot of breakage in its own right), a tool to export the list from a working, tested instance (so you aren't just making them up from guesswork), and report differences between the current install and a list, and probably a tool to spin an iso with packages included for offline installs. Oh, and some syntax in the list to indicate repo changes and replaced and dropped packages. As side effects, repos need minimal coordination, and installs/updates become repeatable. And the stuff you pass around is just human-understandable text, not special-purpose code that only works with one version of one tool in one distribution and needing specially build repositories with subsets of packages. -- Les Mikesell lesmikesell at gmail.com