Re: debtags support proposed for xcontrol
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, Apr 07, 2008 at 01:11:39AM +0200, Simon Richter wrote:
>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. :-)
Just double-checked, and really I didn't :-)
>> 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.
Uh - so xcontrol is meant not only as some control generator, but as a
proposed future metafile standard?
And you want it possible to go both ways - also from control file back
to xcontrol?!?
>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.
Else I will simple try reading again in some hours after drinking some
cola (I don't like coffee)...
>aptitude already allows for "wildcard" searches and installations
>("aptitude search ~tdesktop" shows all packages in the "desktop" task,
I am a big fan of aptitude, and am aware of the complex search features
(am trying to use it to suppress auto-installed packages from a running
system for feeding into cdd-dev or custom-cdd - but more on that some
other time... ;-) )
>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?).
ept-cache ?
>> 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. :-)
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. :-)
(see also my response to Andreas' post later in this thread)
>> [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*.
If you are short on time, then I can recommend simply throwing an
example xconfig file below /usr/share/doc/debian-xconfig/examples !
...and now we can point to this thread from the wiki page, for even more
details. Thanks! ;-)
>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).
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...
* lower to suggest (bonus: hints user even if unavailable for them)
* convert to [arc] construct for arch-all control files
* convert to not+arch for arch-any control files
I too imagine that could be merged with converting not+arch to arch-any.
But it would need a flag somewhere to tell if you wanted lowering or
conversion.
hmm...
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.
- Jonas
- --
* 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+hNPn7DbMsAkQLgRAoMTAJ9+GYlGGXTWdaEOzVcGIMJy6phmlgCcD46w
rS1RxzRyFhokFge/lOKfWss=
=YElg
-----END PGP SIGNATURE-----
Reply to: