[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debtags support proposed for xcontrol



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


Reply to: