Hello again,
Quoting David Kalnischkies (2013-04-23 20:01:10)
> On Tue, Apr 23, 2013 at 12:14 AM, Johannes Schauer <j.scha...@email.de> wrote:
> > 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.
I'm having trouble with implementing this and not breaking the API of
Dpkg::Deps::Simple and Dpkg::Deps::Multiple
Consider the following line:
Build-Depends: foo [amd64 profile.stage1] [i386 amd64]
Which translates to: depend on foo if hostarch==amd64 or if hostarch is either
i386 or amd64 and stage1 compilation is required.
This is just a synthetic example. It might not make any sense to mix
architectures with profiles but maybe there is/will be a scope which makes
sense to mix with architectures. Maybe a scope for the kernel to no longer have
to max architecture and kernel in one name? Who knows.
The problem is, that if it is allowed to mix architecture qualifiers with other
scopes, then
$dep->arch_is_concerned($arch)
$dep->reduce_arch($arch)
$dep->has_arch_restriction()
and the class member (excuse me if my terminology is wrong but I very little
knowledge of perl) named $self->{'arches'} become less meaningful to not
applicable anymore because whether or not an architecture applies is then also
dependent on which other scopes are to be considered.
So either the functions have to get additional arguments specifying which other
scopes/values should be considered enabled or this info is stored in
Dpkg::Deps::Simple itself. Though what troubles me there is that then I don't
understand why arch_is_concerned() and reduce_arch() require to be passed the
host architecture again even though the class they belong to already stores
these in $self->{host_arch}? The internal variable $self->{'arches'} would
completely loose its meaning except if it was known what scopes are
enabled/disabled during the filling of that array.
Alternatively, this can all be circumvented by requiring that a [] bracket pair
with architectures inside must not appear more than once in the qualifier list
plus that the list that does contain the architectures must not contain any
other scope type (no mixing with architectures).
Here another argument about completely forbidding mixing scopes (came up in
#debian-dpkg). Theoretically one can replace mixing scopes with existing syntax
elements of the dependency field. Consider A, B, C, D all of different scope
with mixing allowed:
Build-Depends: foo [A B]
with mixing disallowed:
Build-Depends: foo [A], foo [B]
Unfortunately this becomes less nice for more qualifiers at the same time:
with mixing allowed:
Build-Depends: bar [A B] [C D]
with mixing disallowed:
Build-Depends: bar [A] [C], bar [A] [D], bar [B] [C], bar [B] [D]
What do you think?
cheers, josch
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130518081311.25446.78664@hoothoot
