Re: build profile syntax ideas
Hi David,
Quoting David Kalnischkies (2013-04-23 20:01:10)
> I don't see the benefit of enforcing rules on which scopes can be mixed in
> one […] qualifier. Sure, you can make it a bit simpler, but I am not sure if
> it isn't biting us back one day if we can't mix scopes. Always a bit hard to
> imagine the future, but that we mix 'kernel' and 'arch' in one scope is good
> enough for me to belief that "one scope ought to be enough for anybody" might
> not be true in the end.
Okay, agreed.
> > Since this topic is much about being future proof, I also thought about the
> > choice of the ":" (colon) character to separate the scope from the value in
> > each label like: "<scope>:<value>". If the colon is used for this purpose,
> > then it will be hard to depend upon a binary package that was built with a
> > certain build profile. Currently, the way to depend upon a binary package
> > of a certain architecture is by using "<packagename>:<architecture>". Using
> > this syntax, the natural way of depending on a binary package that was
> > built with a certain profile would be "<packagename>:<profile:stage1>" but
> > there is the problem with those multiple colons. So maybe another character
> > should be used to separate scopes from values? Like the dot:
> > "<scope>.<value>". Is this a valid concern?
>
> I think 2. is intuitive if you use ":", but not so much if you use another
> separator. And I agree, using ":" feels a bit like an overload here.
> A dot doesn't work as it is a valid character in a packagename.
Indeed it is, but the dot would be forbidden to be part of scope names and
their values and the package name would be separated from a potential
"<scope>.<value>" by a colon like: "<packagename>:<scope>.<colon>", no?
> Bonus points for a character which has no special meaning in a shell.
There are sadly only so many ASCII characters. :)
> I wonder if ~ could be used (nobody will think we are talking about home)
Yes, that was my other candidate too. There would also be # and %. At some
point it comes down to painting the bikeshed.
> The "less than" meaning from versions kinda fits for build-profiles, given
> that they are not quiet what the package without ~ would be. Not sure if
> this is the right association for other future usecases though. I can't
> really imagine a good reason to have such dependencies though,
I thought about toolchain bootstraps that need more than one stage:
Build-Depends: compiler:profile~stage1 [profile~stage2], compiler [!profile~stage1 !profile~stage2]
So build depend on a stage1 version of "compiler" for a stage2 build of that
source package and build depend on the full version of "compiler" if not doing
a stage1 or stage2 build. Of course all of the above can also be accomplished
by depending on a binary package "compiler-stage1" instead. I dont know much
about toolchain bootstraps so this might not even be a valid example. Maybe
there exist others.
One other observation I made while writing the above line is, that the "~"
indeed looks quite weird. Unfortunately the situation doesnt considerately
improve when improving the "~" with any of the other candidates...
> as packages build with profiles are supposed to go away after bootstrap,
> aren't they? And if you take profiles to far e.g. like with different libc's,
> you basically have created a new architecture…
Another thing that came up a couple of times was to use build profiles for
embedded builds. For example this way binary packages for emdebian grip or
crush could be directly generated from debian proper source packages. Maybe
there exist binary packages specific to only emdebian that then should depend
on the emdebian version of other packages? Again, just a wild guess of
course...
cheers, josch
Reply to: