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
