Bug#574380: edos-distcheck: Wrong output for | alternative?
On Thu, Mar 18, 2010 at 07:42:37PM +0100, Stefano Zacchiroli wrote:
> I believe this might have caused false negative in the past
> (i.e. packages whose build-deps cannot be satisfied, but for which
> edos-builddebcheck was not reporting it, simply because they were not
> part of the "fake" Packages file generated). Ralf, do you confirm that
> possibility?
That's of course a possibility. Though the cases that I have been told
about always had a different explanation, if memory serves me right.
> > There is a serious problem with addsources.py: it "simplifies" an
> > altenative build-dependency into a single package. On Kurt's example,
> > it changes
> >
> > Build-Depends: libc6-dev (>> 2.3.5) | libc6.1-dev (>> 2.3.5)
> >
> > into
> >
> > Depends: libc6.1-dev (>> 2.3.5)
> >
> > which is hardly acceptable :-)
>
> This, in turn, is by design :-) I don't remember if I or someone else
> added the support for it, but we currently have a list of
> build-essential packages, which currently reads as follow:
>
> buildessentials = ['apt', 'binutils', 'cpio', 'cpp', 'dpkg-dev',
> 'g++', 'gcc', 'libc6-dev', 'make', 'patch',
> 'perl', 'perl-modules']
>
> the function dep_for_me() in the Python code checks, for each build-dep,
> if it is part of that list. If a build-dep is, it gets "simplified
> away". In your example it is trivially the case for 'libc6-dev', which
> gets removed.
>
> Now, as I understand it, the code which currently throws away essential
> build-deps is too simple: it currently does not care about versions at
> all, while it probably should. Is this the root of the problem? If it
> is, there are various thoughts before fixing this naively:
>
> - how can add-sources.py know the version of the build-essential
> packages which will be installed while actually building?
>
> - should it know that in the first place?
>
> I don't currently remember the rationale of ignoring build-essential
> (were there cases where they are not installable, according to their
> deps?), so I'm a bit at loss here ...
I am really disappointed that I can no longer blame python for this bug
(but don't worry, I'll find something else to blame python for :-)
Dropping a build-dependency on a build-essential package is of course
only correct when
- it is an unversionend build-dependency
- and if it occurs as element of a conjunction, not as element of a
disjunction: true and x is equivalent to x, but true or x is not
equivalent to x.
A correct simlification would be to simplify (..|x|..) to True, that
is remove it simply from the conjunct, in case x is build-essential
and has no version constraint. I don't remember either the reason why
we put this stuff in the first place. I guess it was due to some
mis-guided ideas about optimization. I suggest we just scrap it.
-Ralf.
PS: Premature optimization is the root of all evil -- Donald Knuth
(http://c2.com/cgi/wiki?PrematureOptimization)
Reply to: