KDE/JACK rethink -- could go very soon
* qt-x11 free built on hppa.
* Next, it will be uploaded.
At that point,
jack-audio-connection-kit
flac
taglib
openexr
arts
openal (except on m68k)
qt-x11-free
cppunit
qscintilla, sip4-qt3, python-qt3
qca
unixodbc
freetds
geos, gdal, xerces26 (except on m68k), icu, libgdal-grass
...will all be ready to go.
Soon, mono-tools and monodoc will go in; then
dbus
...will be ready to go.
Soon, perl will be ready to go; then
imagemagick (except on m68k)
rrdtool
lm-sensors (once arm build is uploaded)
...will be ready to go
Soon, hopefully, gnuradio-core will build on hppa and it will be ready to
go (except on m68k).
* After the qt build is uploaded,
* Then kdelibs will build on hppa, and it will be uploaded.
* Then kdebase will build on hppa, and it will be uploaded.
* After perl is in testing,
kdelibs
libkexif
kdepim
libkipi
licq
ksimus
wireless-tools
kdebase
kdemultimedia (except on m68k)
...will all be ready to go.
wv2 needs several builds.
After that,
libwpd
koffice
...will be ready to go.
PHP4 is problematic because it still has an RC bug and is missing a lot
of builds. On top of that, it was built against the 'bad' unversioned
version of libssl0.9.8. It also ties the transition into sablotron (essentially
ready to go) and net-snmp (waiting for *openssl*).
Also, bjorn.haxx.se thinks it's waiting for stuff like php-db, but I'm not
sure why.
kdesdk is waiting for subversion, which needs a new upload for an RC bug.
It's also been built against the overly-strict libpng on most architectures,
against the unversioned libssl0.9.8 on arm and m68k, and against libssl0.9.7
everywhere else.
--
I believe that we can get the vast majority of the KDE/JACK stuff in all
together *before* openssl if we do this right. And I think we should.
We will need to render uninstallable parts of php4: php4-sybase and
php4-odbc are the only php4 packages which would be rendered uninstallable.
These wouldn't actually break installability of any further packages.
We would also need to render uninstallable kdesdk-misc from kdesdk; again
this wouldn't break any further packages.
There are probably a fair number of other scattered packages at the top
of the depends tree which aren't ready to go as well (libtunepimp, netapplet
are the ones I know about).
This would unclog over 500 packages (and make the openexr binary installable
again).
Furthermore, waiting until php4 is ready will require delaying the entire
KDE transition until after the libssl shlibs transition, which is a really
bad idea, and would be rather unfair given the unexpectedness of the libssl
transition.
Given the extraordinary size of this, it may be best to do it with a
force-hint of everything we know about (after, of course, the above-mentioned
builds and uploads, and perl entering testing), and clean up the breakage
afterwards; this ensures that as much as possible gets in as quickly as
possible.
It's certainly worth sending to d-d-a to tell everyone not to make gratuitous
uploads, let alone soname changes or transitions. In fact, if no new source
uploads are made except for perl, this should be ready to go within the week
(buildds willing).
--
Nathanael Nerode <neroden@twcny.rr.com>
Make sure your vote will count.
http://www.verifiedvoting.org/
Reply to: