Re: build profile syntax ideas
On Tue, Apr 23, 2013 at 9:15 PM, Johannes Schauer <j.schauer@email.de> wrote:
>> > 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?
Ahhhh. Misunderstanding then. I thought of it more as a problem of:
Find values for X and Y so that it makes sense (and is esthetically pleasant):
<packagename>X<scope>Y<value>:<arch>
My answer: X=~ and Y=. (or anything else expect : really)
As this is something you will have potentially as output in APT/dpkg and
as dependencies.
But given that <arch> is "only" a special type of <scope>Y<value>
we are better of with X=: and therefore potential multiple ":" even though
its a bit unusual at first.
Remains the problem of setting Y:
Y=% looks really noisy, but beside that it is used for encoding its free.
Y=# I would really hate that - shells will think this is a comment …
Y=: feels just wrong to have Y == X
Y=~ really looks strange there, beside that okay I guess
Y=.
…
>> Bonus points for a character which has no special meaning in a shell.
>
> There are sadly only so many ASCII characters. :)
Uhh, we can use ASCII character 29, this isn't taken and "group separator"
sounds so fitting. Just not sure how to output it probably…
(or: We might as well limit the search for printable ASCIIs ;) )
>> 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.
Green with yellow sprinkles. No need for discussion. ;)
But the character used in the "power plant" should be chosen carefully,
as it has effects on the "bikeshed"(s) and it would be bad to have different
characters in the "power plant" and "bikeshed"(s) for the same thing.
(In that case "carefully" is probably just "not :" and the rest 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.
[…]
>> 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...
Shouldn't these be handled more like architectures rather than (mis)using
profiles for it? Indeed, we need a "new" notion of architecture for
it, but still.
i686 on i386 isn't foreign nor is it really native. In the same area I would
settle armel on armhf even grip-any on any or v.v.
(I guess we call this "partial architectures")
Best regards
David Kalnischkies
Reply to: