Hey karsten, > sorry I am writing again, but this time directly about this, and that is > raises this question that was not an issue until now, but I find it to be > very important for the stability of our project, as right now our repo, i.e. > some packages including the puredyne metapackage are broken. I would like to > raise the question of making our tree of packages independant of the Debian > Multimedia repository, the current problem being only one example for > answering -Yup- :-)
[cut] I think this is a bit drastic :) See, p:d relies on 2 repos, lenny and MM that are, just like ours, in constant development. So as a consequence things like broken deps are bound to happen all the time. After 10 months, I saw that happening 3 times in debian and 1 time in MM right now. (Maybe it happenned more, I'm not updating my distro every hour ;) The impact of this is that installing/upgrading some packages is not possible. But this is usually fixed in a few days, usually when the maintainer of the broken package is told so, which is the case here: http://devel.goto10.org/puredyne/ticket/601 The fix takes more time on our side, because we're quite a small team and we have quite a lot of packages to handle :) (and it's summer! :) I'm sure claude will fix that in the coming weeks. And AFAIK, editing a source package depedency list and bumping up a version is way less work and "clean" than rebuilding the package against new dependencies that also need to be built then, in the 1st case you just merge changes and go on working on your package and in the other case you fork, which leads to more work as you would hev to maintain quite a few things, until the day where you see that your fork relies on some new broken things, for which you would have to fork even deeper if you want to follow the non-merging strategy. So for me, this would be a regression in regards of our goals to outsource as much as possible and focus on the end software and the live distro. Furthermore, this is sad to say, but this is a problem only for people who do not have made a full installed p:d yet. Indeed, package managers such as aptitude are clever enough to only update bits of your installation that are fine and postpone the installation of anything that could lead to a broken package. For example right now, most us still have pd-pidip functionnal because their package manager is telling them: The following packages have been kept back: libavcodec51{a} libavformat52{a} while the rest is being upgraded properly. Again we miss one step here, an easy installation setup: Assuming the liveCD/DVD is a *good* snapshot, then: - if you dock + nest, then you use aptitude and it will prevent you to upgrade some packages if they are broken, until this is fixed -> system still works fine and you have all the software - if we provide our own installer that use the CD content to populate the disk, then you use aptitude and it will prevent you to upgrade some packages if they are broken, until this is fixed -> system still works fine and you have all the software - if you just add our repository, then you just learn to live with moment in time where some packages are broken, just the same way when you decide to have lenny or sid as your main install feedback welcome :) > The second issue is something that I realised after poking around with jack > API and also in talking to robert_a on irc: we should contemplate providing > our own jack binary/library. The one in Debian (the latest stable release) > has a load of bugs that are fixed in svn, this also includes new > functionality. if you're sure SVN is stable enough (remember people uses p:d for performances and installations and it would be a problem to switch to a JACK that might have random crashes) then I'm fine with the idea. > Some packages that I can think of from top of my head: > > > - ffmpeg / libavformat / libavcodec > - cinelerra > - avidemux > - jack > - ardour > - mplayer > - mencoder for each of these, we would have to check carefully if it's worth providing these when the ones from MM are already quite good. AFAIK, rob and you had a good experience teaching cinelerra on p:d, so I believe the cinelerra package is good? I used ardour from time to time and MM's is very fine, same for mplayer, avidemux. In the end I agree we might have to provide things differently, but I believe this is too early while there are still more important things to sort, or more "end" software that still need to be packaged :) a. --- [email protected] irc.goto10.org #pure:dyne
