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

Re: build profile syntax ideas



Hi!

On Fri, 2013-08-16 at 02:59:45 +0100, Wookey wrote:
> In the interests of making some progress, I suggest that we simply say
> that arches and profiles can't be mixed in a [], as otherwise we'd
> have to change the dpkg API, and no-one seems very keen on that. 
> 
> Yes it would be nicer, but no-one has thought of a case where it's
> important. We didn't need any such thing with the <> syntax, so if the
> dpkg maintainers want to avoid changing the API, and we can do that by
> only accepting a slightly stricter syntax, then lets do that.
> 
> 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.

> 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. 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.

In case we required something else that could not be expressed in
terms of <> we could always prefix these with sigils or similar for
example (%<> or @<> etc, you get the idea).

Thanks,
Guillem


Reply to: