On Tue, Apr 23, 2013 at 12:14 AM, Johannes Schauer <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/caaz6_faqshx6yewt2qzq9xejjjcqzyb5umt18xhrwf--i8o...@mail.gmail.com
