[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#498300: specify that architecture-specific dependencies must have a non-empty list of architectures



On Fri, Sep 19, 2008 at 11:31:02AM +0100, Colin Watson wrote:
> Seconded in principle (modulo the tab damage in your patch), although

Ooops, sorry, I didn't notice it.

> I'm interested in the following points:
> 
>   * What packages violate this constraint right now?

A quick test is "grep '\[\]' /var/lib/apt/lists/*Packages". Currently it
doesn't return anything meaningful on my machine (amd64 with various
suites). It used to return some packages in the past, and it did return
some packages for Ubuntu no later than 2 weeks ago.

In fact, I've discovered it via python-debian and its new dependency
parser [1]. Some users of that feature reported failures in empty
architecture list cases; cases that I haven't considered because I did
the implementation following the policy only (doing that let me to
implicitly assume that at least one entry in the architecture list is
there, and use it to determine the list "polarity").

[1] http://upsilon.cc/~zack/blog/posts/2008/07/python-debian_w_dependency_parsing/

>   * What happens to packages that violate this constraint right now?

I have no idea, but with the python-debian experience and with the
experience of edos-debcheck, I got convinced that most of our legacy
tools (apt, buildds, ...) are more lax in checking the syntax of
inter-package relationships than what is allowed by policy (which is a
pity).

As per policy the empty architecture list has no defined semantics, I
guess that the only possible behaviours out there are the following:

1) require at least one entry (as did by python-debian)

2) assume a default polarity, this in turn would lead to one of the
   possible two semantics:

   a) (polarity positive) hence empty arch list means "no architecture",
      i.e. useless dependency

   b) (polarity negative) hence empty arch list means "no excluded
      architecture", i.e. always present dependency

We can start betting on this possibilities :-)

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic  -- Manoj \/ right keys at the right time

Attachment: signature.asc
Description: Digital signature


Reply to: