2012/4/29 David Greaves <[email protected]>: > On 28/04/12 09:53, Carsten Munk wrote: > I think I have 2 issues: > * I'm a little worried that you're overloading Group: in the spec file > * I think we (and particularly our vendors) need a more flexible way to store, > manage and interrogate code and package data. > > For the first point it may be that we simply say "In Mer and Mer-based distros > the Group: tag in a .spec file is defined to be the architecural grouping of a > source package, not the user-facing grouping for package installation as it is > in most other distros". This isn't too radical for retail style products whee > app management won't be rpm based but may impact PA and others. I think you might be right, a RPM repository pattern based approach might be better, kind of like how we do package groups (ie, "Mer Core") groups in .ks'es. Especially since it doesn't require rebuilds and changes to a lot of packages, and might be easily able to re-architect and re-group things, as well as spread the approach to vendors.
The story here is that it's possible to add additional information to RPM-md repositories just like patterns/package groups are handled. The downside being they're usually XML :) > So Mer & vendors will need a reasonably simple way to tag source and binary > packages with a variety of group memberships. I've done this previously by > mastering data in a discrete DB but I don't think that's a good approach for > mastering. > > 3. Add a Mer-specific metadata file? I think I'd prefer option 3, due to the flexibility it allows - on a project level, not on package level. > > This looks contradictory: the src tarball defines the single group for all > binaries coming out; but > >> * The goal is to document run-time architecture, not build-time >> architecture -- that is, there is a lot of packages that will be not >> in these groups, which are used for compilation/build phases only or >> are debugging only tools > > ... we're interested in run-time architecture? Aren't some tarballs going to > produce rpms that go into different architecural domains? If not in Mer Core > then in the vendor's codebase? The problem here is that if they go into different architectural domains, you cannot reliably see what happens if you remove a certain component, which is terribly important when doing small cores :) > >> * The goal is to enable vendors with tools and understanding of how to >> fit their components into Mer from an architectural point of view > > Good goal. Don't forget that they'll want to look at a big-picture of Mer from > other perspectives too. > > Will there be any validation or other use of architectural grouping data? I've > heard it mentioned in relation to QA/testing. It'll help understand where to focus the testing, in terms of what is the places we need to test because this is what people would be using typically, and what components are there because the higher levels need them. > >> * If a dependency is only used by one group's components only, the >> dependency ends up within that group. > > Reasonable rule for architecural grouping. Is this implicit or do we have a > one-off pass that sets the group? What happens when a package in a different > domain adds a dependency on such a package? If we've primed the value then is > there a concept of architectural position being marked "potentially > out-of-date" > when an out-of-domain depended-upon is added? Otherwise is there a check > somewhere to say "this component has no arch grouping and is depended on by > packages in multiple domains so needs an explicit value". We have a one-off pass, but is flexible enough to be moved out later to other packages. > >> * The grouping and dependencies of a source package is bound to change >> over time, due to the evolution of components > > True. This introduces issues though as above. Also things like images with one > version of a package will have a different architectural layout when that > package changes - what impact will this have on tools that validate based on > architecture? Part of it is being able to simply query - hopefully we'll find a good model to do this. > >> * The goal is to encourage sane Group: settings of vendor components as well. >> * Mer is meant to be easy to re-architect and change into new exciting >> types of stacks, so the decisions made in here are not ones you >> absolutely have to follow in your product, but they provide a solid >> basis for more people to understand and work with distribution/product >> architecture than previously. >> >> You can see the output of part of this work at >> http://wiki.merproject.org/wiki/Architecture and examples like >> http://releases.merproject.org/~carsten/GraphicsX11.png - These are >> created with a architectural browser, AgileBrowser >> (http://wiki.meego.com/AgileBrowser), which the intent is that we can >> automatically generate data files for this at image creation time, for >> architects in Mer Core and the vendors that use it, to develop and aid >> their product architecture development. > > This doesn't (AFAIK) need the .spec Group: and could easily be done if we used > an alternate store. >
