Proposed removal of unbuildable binaries from lucid (https://wiki.ubuntu.com/LucidPlatformSupportableBinaries)

[Steve Langasek]

Thanks to all for the feedback so far.

Please bear in mind that the proposal is to remove specific versions of
binary packages from the archive.  Source packages will not be removed, nor
will binaries that don't match the version numbers listed in the report.  So
if a fix is known for one of these issues, it's sufficient to push that fix
to Lucid using the normal processes.  If it lands before the removal run,
the binaries will not be removed.  If it lands after the removal run, the
package will have to go through binary NEW, but that's a trivial
requirement IMHO.

So I think there's no need to have a discussion here about individual
packages on the candidate list unless there are false-positives (jetring) or
if you think there are packages missing from the list.

On Sun, Mar 28, 2010 at 12:54:38PM +0200, Loïc Minier wrote:
> On Sat, Mar 27, 2010, Steve Langasek wrote:
> > jetring: jetring 0.18 all

>  Actually I'm not sure the FTBFS report of that one is correct; it
>  seemed to be missing gpg, but gnupg is Build-Essential: yes; I uploaded
>  a package build-deping on gnupg explicitly because I thought this was a
>  problem with the Launchpad chroots, but actually these *do* include
>  gpg, I guess Lucas' chroots were missing it.  Latest upload built fine.

The package has a Build-Essential: yes field in the Packages file, but isn't
the definition of build-essential "the set of packages that
'build-essential' depends on"?  I have no idea what sets or honors a
Build-Essential: yes field in Packages.

Since you've uploaded a workaround there's no need to worry about the
package being removed now, but I wonder if we shouldn't be fixing this in
the build-essential package rather than expecting lucas's rebuilds to honor
what appears to be a non-standard field.

On Sun, Mar 28, 2010 at 03:24:11PM +0200, Stefan Potyra wrote:
> > gcc-4.2: gcc-4.2-base 4.2.4-5ubuntu1 all
> From a quick grep, gcc-4.2 seems to be a build-dep of sdlmame (multiverse)
> and a dependency of gdc-4.2 (universe). Maybe we should take a look at these 
> as well?

Here's what the archive spits out:

$ checkrdepends gcc-4.2 lucid
-- lucid/universe build deps on gcc-4.2:
hurd
-- lucid/universe build deps on g++-4.2:
chromium-browser
debtags-edit
-- lucid/universe amd64 deps on g++-4.2:
geordi
-- lucid/universe i386 deps on g++-4.2:
geordi
-- lucid/universe amd64 deps on libgfortran2:
abinit
libcojets2-gfortran
libeurodec1-gfortran
libgeant321-2-gfortran
libherwig59-2-gfortran
libisajet758-3-gfortran
libpdflib804-2-gfortran
libphotos202-1-gfortran
libphtools2-gfortran
openmx
zivot
-- lucid/universe i386 deps on libgfortran2:
abinit
libcojets2-gfortran
libeurodec1-gfortran
libgeant321-2-gfortran
libherwig59-2-gfortran
libisajet758-3-gfortran
libpdflib804-2-gfortran
libphotos202-1-gfortran
libphtools2-gfortran
openmx
zivot
-- lucid/universe powerpc deps on libgfortran2:
abinit
libcojets2-gfortran
libeurodec1-gfortran
libgeant321-2-gfortran
libherwig59-2-gfortran
libisajet758-3-gfortran
libpdflib804-2-gfortran
libphotos202-1-gfortran
libphtools2-gfortran
openmx
zivot
-- lucid/universe ia64 deps on libgfortran2:
abinit
openmx
zivot
-- lucid/universe sparc deps on libgfortran2:
abinit
libcojets2-gfortran
libeurodec1-gfortran
libgeant321-2-gfortran
libherwig59-2-gfortran
libisajet758-3-gfortran
libpdflib804-2-gfortran
libphotos202-1-gfortran
libphtools2-gfortran
openmx
zivot
-- lucid/universe build deps on libstdc++6-4.2-dev:
wine
wine1.2
-- lucid/multiverse build deps on gcc-4.2:
sdlmame
$

I think it would be ok to leave the reverse-deps uninstallable, but I don't
want to leave reverse-build-deps here since that just moves the same problem
up the stack.  wine is a false-positive since it has an ORed build-dep on
libstdc++-dev as guaranteed by build-essential.  chromium-browser is a
false-positive because it build-depends on g++-4.3 | g++-4.2 (but why
doesn't it just use the default g++? :/ ).  That leaves hurd, debtags-edit,
and sdlmame to be resolved.

The hurd and debtags-edit build-deps are resolved in unstable, so it looks
like a sync / merge will take care of us.  sdlmame is not in Debian - does
someone want to take responsibility for this package?

Stefan, do you agree that taking care of the reverse-build-deps is
sufficient, and the reverse-deps can be handled as normal uninstallable
packages?

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20100328/e543232f/attachment.pgp