Hi, On Mon, Apr 07, 2008 at 02:27:59PM +0200, Jonas Smedegaard wrote:
> >The general idea is that any tool capable of parsing debian/xcontrol > >shall do so, but no guarantee is given that the file format does not > >change. The xcontrol tool generates a policy-compliant control file > >from that so that the maintainer doesn't need to update two copies as > >one can always be regenerated from the other. > Uh - so xcontrol is meant not only as some control generator, but as a > proposed future metafile standard? Yes and no. The plan is to implement control file extensions via xcontrol so they can be used in packages, and when a certain extension proves to be useful, it can be implemented in dpkg proper and the transformation removed from the xcontrol tool. > And you want it possible to go both ways - also from control file back > to xcontrol?!? The control file is a valid xcontrol file, so switching over to xcontrol is easy -- the work lies in actually using the extra features (which means for example determining which build dependencies are needed on the host and which are needed as target packages). > >It would simplify the process, not automate it. The control file is > >fixed after uploading, having any kind of dynamic data influence it > >would make autobuilds fail during "xcontrol check"; also, the problem > >of prefiltering the package lists remains (I plan to add a --suite > >option that denotes the compatibility level for the control file, which > >could in theory be overloaded to also select that suite as a package > >source, however that would mean that there has to be a way of adding > >new "suites" on the spot). > err - my heads spins from the above. Could you perhaps elaborate some > on this. It seems quite important, but I can't parse it right now. The main problem with pulling in external data is determining which data sources should be applied. People can work on multiple projects at the same time as long as they take proper care, so they might have additional APT sources configured, and only some of these should be used as data sources; which of them depends on the package (when doing CDD work, you want to include your CDD repos, when doing Debian work, you don't). There is just no proper place to put this information. To have at least some degree of reproducability (some might say even that is too little), all of this would have to be stored in the package (i.e. the xcontrol file would also have to state that the Debtags information would be coming from the "Debian" repository), which makes it hard to move the package between distributions or even synchronize them between a CDD with its own repo and Debian. > >Yes. My suggestion would be to go for the substvars approach first, and > >later on replace that with the necessary aptitude bits. The xcontrol > >tool could even handle that transition. :-) > I favor the dynamic-at-unofficial-build-time static-officially approach > for my purposes, so I probably won't at first. But I sure find it > interesting to offer Debtags resolving also for simpler use cases than > cdd-dev using developers. :-) Indeed, I also like the idea of resolving them once and then having a static control file better than the substvars approach. My point is that via substvars, it is considerably easier to implement (the problem of selecting data sources remains for manual builds, however we can assume that autobuilders will have exactly the right sources configured, otherwise they could be pulling in packages from unofficial sources as build-deps). > >Well, there are manpages, but the file format is indeed a bit > >underdocumented *cough*. > If you are short on time, then I can recommend simply throwing an > example xconfig file below /usr/share/doc/debian-xconfig/examples ! There is one, in debian/xcontrol :-) [architecture specific dependencies] > Hmm - what I would want is to *not* express archs manually: be able to > express a list of package not caring about the archs they are availaible > for, and have the tool either... Hm, while I still don't like the idea of not-so-reproducible builds, I think we can make this work if the spec allows an xcontrol aware autobuilder to determine on its own that the package would change, were it to be rebuilt at this point, and either schedule a binNMU on its own at this point or at least alert to the problem. At least this is the place where I can see actual work being saved. > * lower to suggest (bonus: hints user even if unavailable for them) That means the syntax would have to allow us to specify whether a package should be suggested or omitted at this point. > * convert to [arc] construct for arch-all control files > * convert to not+arch for arch-any control files [arch] only works for build dependencies. The "not+arch | ..." method has the advantage that it doesn't need substvars and so no change to the build process is necessary, but I can see how it makes CD building more complex. > thinking some more I actually prefer the -Relaxed feature over merging > with conversion: I can imagine wanting both in same source package (one > for meta packages and another for some binary arch-specific tool > included with same source. These are orthogonal features anyway, so you can use both. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
