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

Re: build profile syntax ideas

+++ Guillem Jover [2013-08-16 14:15 +0200]:
> > The current iteration of the Spec, after some refinement at debconf, is here:
> > https://wiki.debian.org/BuildProfileSpec
> I've not checked that yet, will try to do that during this weekend.
> ISTM I had an issue with the new field being Profile instead of
> Build-Profile, for example. Will need to check my notes.

Please do - we'd really like to lay this to bed and actually implement
something in the archive.

> > So I think I am suggesting that the entry "We propose that literals of
> > different namespaces can be mixed within a disjunction. Therefore, the
> > following would be legal:
> > 
> > Build-Depends foo [arch.i386 !profile.cross]"
> > 
> > Is changed to say that you can't do that, and have to do [i386]
> > [!profile.cross] instead.
> I've been pondering about the (old) updated proposal, and while I can
> see Ian's argument and can agree with the problems he presents, I
> can't really see using a syntax like «pkg [foo] [bar]» as something
> desirable given the current context.

As josch pointed out, it would actually be  pkg [foo], pkg [bar]

> I'd expect the failure modes for
> those to be silent, and it might imply wrongly parsed or computed
> depdendencies. I want old tools to break spectacularly so that they
> can be spotted and fixed. Using the same bracket characters for
> different blocks on the same dependency also seems confusing, and
> mixing different namespaces for something that has only expected
> architecture up to now more so.
> While the bracket characters are limited, and using <> can be
> considered to waste them when we could reuse others, it's the cleaner
> and safer option. And I'm fine with allowing any namespace there, not
> just build profiles, so that we can have a slightly more future proof
> syntax. We could even consider switching from [] to <arch.foo> if
> desired for example.

We're absolutely fine with the <> syntax, which is already implemented
(and to be honest I prefer the look of it in practice). Are you
proposing pkg <!profile.stage1> as opposed to pkg <!stage1>?

We can adjust the patches for that if so. 

Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM

Reply to: