On Tue, Apr 15, 2003 at 12:31:44PM +1000, Paul Hampson wrote: > On Wed, Apr 09, 2003 at 08:30:42PM +0200, Sven Luther wrote: > > On Wed, Apr 09, 2003 at 05:59:26PM +0200, Michael Banck wrote: > > > On Wed, Apr 09, 2003 at 04:40:31PM +0200, Sven Luther wrote: > > > > depth, i cannot help all that much about it, and libvorbis is a valid > > > > candidate, but his installation would break 107 or so packages in > > > > testing, and i have not really the intention to check by hand all those > > > > 107 packages. I believe it is just some packages that need to be rebuilt > > > > due to the libvorbis0a thingy, not sure though. I already checked the > > > > primary dependencies of all our packages (around 40) by hand, which > > > > > > apt-cache showpkg libvorbis0 prints out just a couple of packages. Is > > > > You have to look at the update_output.txt file, it shows : > > > > * alpha: adonthell, alsaplayer, alsaplayer-alsa, alsaplayer-common, > > * alsaplayer-esd, alsaplayer-gtk, alsaplayer-nas, alsaplayer-oss, > > * alsaplayer-text, amoeba, artsbuilder, audacity, bitcollider-plugins, > > * black-box, brahms, bugsquish, bumprace, cantus, castle-combat, > > chromium, > > * circuslinux, clanlib-dev, clanlib-vorbis, crimson, criticalmass, > > csmash, > > * defendguin, easytag, enigma, fags, frozen-bubble, gcompris, gemdropx, > > * gjay, gl-117, gltron, gqmpeg, gtoaster, heroes-sdl, icebreaker, jack, > > * jumpnbump, kdebase-audiolibs, kdebase-dev, kdemultimedia-dev, > > kreatecd, > > * langband-zterm, lbreakout2, lgeneral, libarts-mpeglib, libopenal-dev, > > * libopenal0, libsdl-mixer1.2, libsdl-mixer1.2-dev, libsdl-ocaml, > > * libsdl-ocaml-dev, libsdl-perl, libsdl-ruby, libxine-dev, libxine0, > > * ltris, madbomber, mangoquest, mirrormagic, moon-lander, mp3blaster, > > * mp3c, mp3kult, mpeglib, noatun, noatun-plugins, penguin-command, > > prboom, > > * pygame, python-pyvorbis, race, ripperx, rockdodger, rocks-n-diamonds, > > * saytime, simplecdrx, sinek, sox, sox-dev, sweep, terminatorx, > > timidity, > > * toppler, tuxpaint, tuxpuck, tuxracer, tuxtype, vectoroids, vegastrike, > > * vorbis-tools, vorbisgain, vsound, xine-ui, zinf, zinf-extras, > > * zinf-plugin-alsa, zinf-plugin-esound > > Is this with libvorbis being 'recur'd by the testing script? If I read > the documentation correctly, then: > libvorbis will be rejected because it breaks everything that depends on > libvorbis0. > Everything that now depends on libvorbis0a will be rejected because > their dependancies cannot be met...
Ok, i have a partialy more detailed list, all done by hand : * adonthell : hppa * alsaplayer : Valid Candidate. * amoeba : arm, sparc built ok, but package disapeared. * kdemultimedia : 4 RC bugs, out of date on s390. * audacity : 1 RC bug, out of date on hppa and powerpc. * bitcollider : OK. * black-box : Valid Candidate. * brahms : Only 3/10, alpha, arm, hppa, m68k, s390, kdemultimedia. * bugsquish : OK. * bumprace : OK. * cantus : Calid Candidate. * castle-combat : Only 0/10. * chromium : 1 RC bug, out of date on arm. * circuslinux : OK. * clanlib : 3 RC bugs, need a rebuild, libdirectfb & libvorbis dependant. * crimson : m68k. * criticalmass : mips/mipsel. * csmash : Valid Candidate. * defendgui : OK. * easytag : 1RC bug, ia64. * enigma : Valid Candidate. * fags : 3 of 10 days. * frozen-bubble : alpha, arm, m68k. * gcompris : 2 RC bugs. * gemdropx : OK. * gjay, gl-117, gltron, gqmpeg, gtoaster, heroes-sdl, icebreaker, jack, * jumpnbump, kdebase-audiolibs, kdebase-dev, kdemultimedia-dev, kreatecd, * langband-zterm, lbreakout2, lgeneral, libarts-mpeglib, libopenal-dev, * libopenal0, libsdl-mixer1.2, libsdl-mixer1.2-dev, libsdl-ocaml, * libsdl-ocaml-dev, libsdl-perl, libsdl-ruby, libxine-dev, libxine0, * ltris, madbomber, mangoquest, mirrormagic, moon-lander, mp3blaster, * mp3c, mp3kult, mpeglib, noatun, noatun-plugins, penguin-command, prboom, * pygame, python-pyvorbis, race, ripperx, rockdodger, rocks-n-diamonds, * saytime, simplecdrx, sinek, sox, sox-dev, sweep, terminatorx, timidity, * toppler, tuxpaint, tuxpuck, tuxracer, tuxtype, vectoroids, vegastrike, * vorbit-tools : Valid Candidate. * vorbisgain : Valid Candidate. * vsound : OK. * xine-ui : 4 RC bugs, arm, m68k, mips, mipsel, s390 * zinf : 1 RC bug, alpha and hppa. The problem is that the version of let's say xine-ui in testing is dependent on libvorbis0, which is not available in the unstable package, and thus you need a new version of xine-ui to be able to enter testing which depend on libvorbis0a. In turn the xine-ui could be dependant on other package, which in turn are not able to enter testing, and thus holding up the packages. As an example, we have around 40 or so ocaml packages, which are all ready to enter testing (because we were holding a mini-freeze these past month, and actively hunting and working on bugs and build issues), but this is all work for nothing, since we are hold up by postgresql and libvorbis, which we don't really use apart from two small binding libraries. The postgresql seem to be in good way of being solved, but will in turn be hold back by python and perl, if i read the dependency graph correctly. I see only three ways that this can get handled : 1) We hold a real freeze, and actively hunt bug, rebuild problematic packages and such. 2) We remove the packages holding up the testing migration. Not automatically and in a huge way, but as a concerted and case by case effort to balance the removed packages from the ones entering testing. The removed packages will enter testing again once they are ready. 3) We do a bit of testing-update rebuilding. I don't know if this is really easily feasible today, but it would be nice solution, a bit similar with the two level unstable that some spoke of. The idea is to have a small pool, which consist of libvorbis and all the packages in testing that would get broken by it. Then you rebuild all these packages with testing + libvorbis. Once everything is built, it will enter testing, and the huge amount of packages will not be hold back by one or the other libraries, possibly for long times, as wad the case with libc6. Well, maybe a separate pooling mechanish for library or more exactly hugely depended upon packages would be a nice solution. Wasn't is exactly that what was discussed back then when we spoke about pools ? > I guess someone has to add a hint to the testing script to recur over > libvorbis and see if upgrading it would mean less breakage than > currently exists... Which is probably true if all the packages which > depend on it are "valid candidates". Hardly, there are many RC bugs or FTBFS bugs in those. I think the main issue is that the PTS does not show the list of packages holding up. IT is not as easy, since there may be more than one possible update path, but still everything would be better than what we have now. I have been trying to make a little program that would parse the update_output and update_excuses as well as the testing/unstable package list and generate more info, but i have been hold back by the fact that the update_output is really not all that informative and easy to parse. I guess i could modify the testing script, but i don't (yet) speak python, and it is not even sure that my changes will be accepted. The idea is that since the testing scripts have all the needed information, they would much easilier be able to output this data in a usable format. But then, all my attempts at communication about this have been meet by silence, as usual. Also, notice that most of the packages that are valid candidate are only such because they were not rebuilt since the libvorbis0a change, any modification of them will break them also. > If libvorbis is 'recur'd unsuccessfully, then you'll get a complete list > of the packages in testing which would be broken by libvorbis and which > can't be updated to a version that depends on libvorbis0a. On _all_ > arches, not just one. Well, that is not a problem, most of these packages list one arch, but the result would be the same for all arches. The real problem is to be able to identify those packages easily, with a link from the PTS to the corresponding pts package, and maybe a hint at what is the reason/status of the package (RC bugs, valid candidate, build problems, time delay, dependencies). Friendly, Sven Luther