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

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: