Re: debtags support proposed for xcontrol
Hi,
On Sun, Apr 06, 2008 at 11:39:57PM +0200, Jonas Smedegaard wrote:
> Didn't know you were subscribed to d-custom. Safes me from writing that
> direct email to you that I had in mind for tonight :-)
Didn't know that myself, thought you had CCed me. :-)
> If I understand the fundamental logic of xcontrol correctly[1], it
> already regenerate the control file, the currently implemented features
> just only triggers changes for features not currently handled in Debian
> build daemons anyway (cross-compiling).
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.
I also encourage users to invoke "xcontrol check" early during the build
to see if the control file is up to date.
> The benefit of -Debtags
> support in xcontrol is to offer CDD developers a method to automate that
> process.
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).
Hence my suggestion of implementing that inside aptitude, since it has a
good overview what package sources the user has selected, and it allows
you to get rid of the metapackages altogether (or replace them with a
small package that adds a configuration setting to apt stating that
packages matching a certain criteria should be automatically installed
on sight), and thus overcome the "all-or-nothing" limitation of
metapackages that might be confusing for the user if some package
required by the metapackage is currently uninstallable.
> I know of two policy compliant methods to handle regenerating control
> file (which btw might be relevant for you to mention in README.Debian of
> your package):
> a) Always regenerate but fail build if control file content change
That is essentially what "xcontrol check" does, only that it compares
the file on contents, not on literal equality (i.e. reordering lines
will not trigger it).
> Both methods comply with the words of Debian Policy, but only the second
> follows the _intend_ of it (as I interpret it): Method a) is IMO only
> sane to use if the conditions triggering an update do not change during
> the lifetime of a released distribution.
Yes, that is part of the current xcontrol design. If the generated
control file would be any different, that warrants manual inspection.
> The proposed -Deptags feature, however, will cause FTBFS with method a)
> even on a released distro, due to debtags data being maintained
> independently from package releases. So the recommended use of this
> xcontrol feature is with method b).
I can see another way of implementing that in a policy compliant manner:
If the "Depends-Debtags:" field exists, append "${debtags:Depends}" to
the normal dependency spec during control file generation, and determine
the list of packages at compile time with a separate tool that reads the
spec in the xcontrol file and generates appropriate substvars.
[aptitude hacking]
> Interesting idea. But a radical change. For some CDDs it still might
> make sense to resolve dependencies at build time (my mind is crackling
> now, trying to imagine to possible problems). Example: CD build tools
> needs rewriting how to calculate space for a set of packages, if their
> install-time dependencies should want to be fulfilled.
aptitude already allows for "wildcard" searches and installations
("aptitude search ~tdesktop" shows all packages in the "desktop" task,
and that also works for "install"), so all that would be needed is a
mechanism to pretend that the metapackage has a dependency on such a
pattern. I see the point with the CD build scripts; ideally we'd have a
common resolver that could be used by everyone (can this be split out of
aptitude?).
> I want something now. Like it seems you want smarter cross-building
> support now. Wasn't that the itch you scratched by inventing
> debian-xcontrol?
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. :-)
> [1] debian-xcontrol seems to completely lack documentation in the
> package itself - AFAICS the wiki page is only place documenting the tool
Well, there are manpages, but the file format is indeed a bit
underdocumented *cough*.
About your other idea, looking whether packages are available on an arch
and omitting them if not: can be done, something similar was on my list
already (although the static version where "foo [i386]" would be
replaced by "not+i386 | foo"; I can certainly see that happening with
substvars as well for Arch: any packages, but it will be difficult for
Arch: all as we cannot see what the other arches have).
Simon
Reply to: