Bug#545381: edos-builddebcheck: Always consider built-essential packages installable
On Fri, Nov 20, 2009 at 05:46:58PM +0100, Kurt Roeckx wrote:
> On Tue, Sep 29, 2009 at 11:16:31PM +0200, Kurt Roeckx wrote:
> > On Sun, Sep 27, 2009 at 10:07:50PM +0200, Kurt Roeckx wrote:
> > > I'm now running your version, but with the deb822.py merged into
> > > it again.
> > [...]
> > > I've just added hurd-i386 to buildd.debian.org, and they have
> > > the following problem:
> > > debhelper (= 7.4.2) depends on perl {perl (= 5.10.0-19)}
> > > perl (= 5.10.0-19) depends on hurd {hurd (= 20090404-1)}
> > > hurd (= 20090404-1) depends on sysv-rc {sysv-rc (= 2.87dsf-6)}
> > > sysv-rc (= 2.87dsf-6) depends on insserv (>> 1.12.0-10) {NOT AVAILABLE}
> > >
> > > Since perl is one of the packages that's build-essential,
> > > they shouldn't get that error.
> >
> > So looking at what is happening, it seems you remove
> > the dependencies for build-essential packages from
> > the source packages. But those don't build-depend
> > on it in the first place. You need to change
> > the Depends on the Packages themself, so
> > that the files going to edos-debcheck
> > does not have Depends: perl for debhelper.
> >
> > I've tried adding a package that provides all the build-essential
> > packages in 1 package, but that seems to cause problems too.
> >
> > This has atleast 2 problems:
> > - Versioned depedencies don't work. We have things like
> > - libtext-format-perl (= 0.52-21) depends on perl (>= 5.6.0-16)
> > - autoconf (= 2.64-4) depends on perl (>> 5.005)
> > (I've only seen it with perl so far)
> > - You need to add provides for all the provides the packages
> > you try to replace have. And perl has alot of them.
> >
> > It might also need to be arch specific, I think hurd has conflicts
> > with packages that are essential on other arches.
> >
> > This atleast seems to be giving reasonable results, it might
> > not be perfect, but would atleast not get us completly stuck.
>
> So does someone have a better suggestion on how to get this fixed?
> I would like to see the options about dropping Depends.
We are currently preparing a new release of the underlying library
and the tools that are using them (this will be the dose3 library).
This will happen in the next weeks, and that new version will have
a native edos-builddebcheck (without need of a python wrapper). The
new library will allow us to realise much more easily manipulations
on the package universe.
Anyway, we will have to decide what exactly we will implement. The
current proposal (after discussion with zack) is the following:
- we construct a set BE as follows: at the start it only contains the
package "build-essential". Then we extend the set by any package from
the Packages file that build-essential directly or indirectly depends on.
For calculating BE we would also follow through alternatives, that is if
a build-essential package depends on a|b we would both include a and b in
that set.
- For each package in the set BE we set its list of conflicts to the
empty list.
This would mean that all build-essential packages and all their (in)direct
dependencies *that are present in the Packages file* would be assumed to
be always installable. This would probably give some false positives
(indicating packages as buildable when in reality they are not) but that
seems acceptable.
However, if for instance a build-essential package does depend on a package
p that does not exist in the Packages file than we wouldn't assume p to
be installable. Is that OK?
-Ralf.
Reply to: