On 28/04/12 09:53, Carsten Munk wrote: > Hi all, > > As some know, I've been working a while on how we can auto-document > and explain the Mer architecture and as part of that I'll be sending a > bunch of .spec/.yaml changes for each of the source packages, changing > their Group: fields
Overall I think this is really useful and a huge step in explaining Mer. Kudos. 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've had a lot of experience with data design and grouping and heirarchies is one of the areas that *always* goes wrong :) Used alone, the word 'group' means what the listener wants it to mean; we (and our downstream) will have many kinds of groups and it's safest to be explicit. Eg: when you have your head firmly in architecture space then "group" means architecture group. When you have it in people-management space it means "packages managed by this team". When you have it in kickstart space it means "packages installed by this label" etc etc. 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. Given I don't really think Group: is the best solution - what alternatives are there? 1. Extend .spec to allow multiple group 'types'? 2. Extend the .yaml? We'd need to mandate it for all packages we want this metadata for. 3. Add a Mer-specific metadata file? 1. just seems like a bad idea. The .spec is used by a lot of tools, has a well defined format and is well established. I propose to extend Spectacle's .yaml and possibly permit a "this .yaml doesn't own the .spec file" flag to make migration to 100% yaml coverage easier. Ideally we could do this in a way that permits arbitrary extension of the data structure through plugin element handlers. More comments inline below: > To understand the reasoning behind the architecture, I'd like to note > a few points: > > * A group covers all binary packages a source package produces 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 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. > * 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". > * 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? > * 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. > Let me know if there's any problems with the suggested groupings and > let us have a discussion about these. The architecture should > naturally be seen in collaboration with full products (Core + hardware > adaptation + UI) and hence groupings should be able to scale to that. > > Future work can be declaration of D-Bus interfaces and other types of > interfaces, to understand the true dependencies and automatic > understanding of API/ABI changes -- for example being able to check if > a D-Bus API change will be backwards compatible. This is another plus for extending the yaml to include richer architectural definitions. Not commented on the actual allocation of packages to domain or the domain structure. I'll do that later :) David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..."
