Re: build profile syntax ideas
On Tue, Apr 23, 2013 at 12:14 AM, Johannes Schauer <j.schauer@email.de> wrote:
> Quoting Raphael Hertzog (2013-04-21 21:49:55)
>> So I tend to agree with Ian, it would be much more future-proof to have a
>> generic syntax instead of introducing another metacharacter.
>>
>> (Furthermore the ">" and "<" are already used in many dependencies, so
>> it would not really stand out in the dependency line.)
>>
>> And we already have wishlist request to extend the expressiveness of
>> dependencies so that some dependencies are only considered if a third
>> package is installed, this generic scheme could be a way to do it:
>>
>> Package: iceweasel
>> Depends: [...], iceweasel-gnome [if-installed: gnome]
>>
>> So I believe that even if we can't foresee the future, I can easily
>> imagine other use cases for such a generic dependency tagging mechanism.
>
> Raphael, your argument is very convincing and I am now even more in favour of
> Ian's proposal, thanks! Can you list some of those other use cases you said you
> can imagine? Maybe that helps to better decide upon the following:
While I can totally imagine this as a way to codify why a package is
recommend/enhances, I am not that much in favor of having conditional
depends (or even worser: pre-depends, breaks, …).
In this example, it is not the job of iceweasel to announce that there is
a package to better glue it into gnome. It should be the iceweasel-gnome
package saying that you want it, if you want iceweasel glued to gnome.
For desktop environments it might be manageable, but it becomes intolerable
with language packs (the other primary example) and for me as a new
translator/desktopinventor its a lot easier to provide a glue on my side
rather than convincing the maintainers of e.g. iceweasel to if-depend now
on my package which might not even be in Debian just yet, but in my pet
derivative because of $reason …
This of course means that the package managers have to do the heavy lifting
of providing a good experience for the user to discover those possible
enhancements to choose from (if not installing stuff like language packs
by default), but with 30k (and counting) packages we aren't able to paper
over this problem for much longer anyway, even if we hack it with if-depends,
which we have to wait for at least jessie+1 to use them, even if we implement
them now.
> So if we agree on Ian Jackson's proposal, then there are a few other details
> that have to be decided upon. One is between the following two variants:
>
> Build-Depends: huge (>= 1.0) [i386 arm] [!profile:embedded !profile:stage1], tiny
>
> Build-Depends: huge (>= 1.0) [i386 arm] [profile: !embedded !stage1], tiny
>
> Both versions were also brought up by Ian Jackson in his initial email. Is
> there any technical reason to prefer one over the other? Otherwise, the
> advantage of the second is, that it prevents mixing different scopes in one
> [...] qualifier and is also a bit shorter (but also more irregular).
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.
> Incidentally, the second option was also chosen by Raphael for his
> "if-installed" example above, so maybe the second option is the more intuitive
> one?
>
> 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.
Bonus points for a character which has no special meaning in a shell.
I wonder if ~ could be used (nobody will think we are talking about home)
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, 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…
Best regards
David Kalnischkies
Reply to: