Re: debtags support proposed for xcontrol
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, Apr 06, 2008 at 08:39:37AM +0200, Simon Richter wrote:
>Hi,
Hi Simon.
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 :-)
>On Sun, Apr 06, 2008 at 03:51:08AM +0200, Jonas Smedegaard wrote:
>
>> For your information, I have proposed to add support for debtags
>> expansions to debian-xcontrol.
>
>I'm not sure that would be practical.
>
>Debian policy disallows us from regenerating the control file because
>it should never contain dynamic information, so when a new package is
>added that matches the selected criteria, it will still require manual
>action, so the benefit is minimal.
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).
I do see a benefit. CDDs often includes one or more metapackages
depending on "all available packages fulfilling some criteria" (maybe in
addition to additional packages not part of same criteria - like "...and
use postfix instead of exim, just because I fancy that"). Currently
those package lists are maintained by hand. The benefit of -Debtags
support in xcontrol is to offer CDD developers a method to automate that
process.
Due to CDD metapackage package dependency lists currently being
maintained by hand, they tend to only infrequently be updated.
Implementing this xcontrol feature makes it possible for CDD
developers to...:
1) autobuild auto-updated packages unofficially (comparable to
packages built automatically from VCS snapshots)
2) manually trigger an update locally, and commit it to VCS
Maybe it makes sense to elaborate some on this...
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
b) Only regenerate when some environment flag is set
(an example source package using a) is linux-2.6, and b) is yaird).
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.
Current features of xcontrol deals with architectures and
build-dependencies, which seldom change, and never in an officially
released distribution.
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).
>At the same time, it is hard to implement, because there is a desire to
>allow backports to pull the package list from stable+backports, while
>for unstable it needs to be pulled from unstable and so on, so we'd
>need a way to specify which sources are relevant, essentially
>duplicating large parts of APT.
Good point.
I would suggest implementing the proposed functionality now, and then
afterwards work on improvements to support expressing more flexible ways
to define debtags source(s) to use than the currently proposed "system
default only or local only".
Even my limited proposal is far better than current hand-editing (which
does not treat backports specially either :-P )
>I think the best way to implement functionality like that would be to
>teach aptitude that all packages matching a certain pattern should be
>installed, and then pre-set that in the CDD to auto-install packages
>from a certain task or matching a tag specification (i.e. make this a
>runtime decision). There could/should also be a synergy effect with the
>fix for the long-standing issue of updated installations missing
>features that freshly-installed installations have -- a mechanism to
>automatically install all new packages above priority standard would
>fix that.
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.
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?
Kind regards,
- Jonas
[1] debian-xcontrol seems to completely lack documentation in the
package itself - AFAICS the wiki page is only place documenting the tool
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFH+UMtn7DbMsAkQLgRAtEJAKCS4zOVzHn4Hy0SHcGe4/rHaGo84QCdGUm+
I3GqTQ9sN/zVHYo1pwJcDr0=
=q3ut
-----END PGP SIGNATURE-----
Reply to: