Ricardo . said : > You made really good points, Aymeric. I think the best approach would > be to have a repository with backported audio and video stuff, so that the > user > can install the latest tools he really needs. That's what has worked best for > me until now. Why upgrade the whole system if all I want is to have the latest > JACK, Ardour, Puredata and Rosegarden, for example? So, what I personally do, > is to install Debian Stable and backport some programs that are more essencial > to my music work.
Do you actually manualy backport packages from, say testing or unstable, or do you simply do some pining? > Relying on testing brings many problems, like you said, and I > would never trade Debian's stability and flexibility with something like > Ubuntu. And, if the trend continues, we surely will have in a year or so a > Lenny-and-a-half with upgraded kernel and xorg drivers, that was an excellent > innovation from the Debian folks. > Considering the pure:dyne structure, I think we could have, like you > said, one testing repository to upload new audio and video packages and a > relatively stable one, where we could simply ensure that aptitude wouldn't > brake on a regular system. > All that said, I like what pure:dyne is right now, focused on it's > live releases. These ideas would only be an improvement, but it would also > possibly bring much more work to the developers. I'm not sure if it would really bring that much more work (maybe I'm a bit over enthusiastic here..) At the moment we waste quite some time fixing bits and pieces when we release a new version of the live distro because from one moment to another many things have changed. Also, manually resolving conflicts or try to maintain large metapackages is just not working at all in combination of testing/unstable. > Joining pure:dyne packages > with Debian apt's tree should be the highest priority in my humble opnion. Yes, that's our priority. > Ricardo > > > 2009/3/31 Aymeric Mansoux <[email protected]> > > Ricardo . said : > > A stable puredyne metapackage would be a great idea. I > understand > > that the main focus from puredyne are the liveCD and liveUSB systems, > but > it > > would be also awesome to have a repository dedicated to deliver Debian > Stable > > newer versions from art apps, so that we can build a DAW upon a solid > basis. It > > is, however, something similar to what 64studio and Musix are, but both > have > > it's problem: 64studio's development is really slow nowadays and both > don't > > offer so many art programming tools as puredyne does. I'm installing > probably > > this week a GNU audio system on some computers at the Electronic Music > Lab our > > university here in Brazil and, as it stays now, I will install Debian > Lenny and > > compile in a regular basis the newer versions from software we will be > using to > > our audio work. A stable puredyne repository could change that in the > near > > future. > > > > Ricardo > > Hi Ricardo, > > I think we are now facing what 64Studio faced at some point, which is > how to deal with the slow development cycle of Debian. Their solution if > I remember correctly was in the end to make a snapshot of Debian and > maintain it on their own, then recently I believe that they completely > switched to Ubuntu, probably because building on top of Ubuntu or making > a snapshot of Ubuntu is more simple. > > Now, we are of course focussing a lot on the live distro, but at the > same time, we really need a good Debian repos for solid installs that > needs full updates. > > I think this is an open discussion with everyone. For example, what are > the pros and cons: > > * work with stable > > pros: - it is stable, so dependencies are more robust (only security > fixes or major bug will be fixed) > - using metapackages is not a problem > > cons: - it will become outdated faster, not good for recent hardware > (we can always update kernel of course, but we might have to > eventually backport more tricky things like acpid, udevd, .. > xorg even) > - we still need a testing repos, for ... testing new software > how do we do it? our testing repos would be in fact meant for > testing packages against lenny (and NOT squeeze) for future > inclusion in our stable repos. > - some software will need backporting > - the live distro can including any complex match of software > because we use a lot of pinning when it's built. So to keep a > full install fresh with some software that we are not packaging, > the user will also have to do some pining. > > * stick with testing/unstable mix > > pros: - very up to date > - allow to build more bleeding edge stuff > - more forgetful and quick and dirty approach to building an > operating system. > > cons: - hard to fix the mess for a newbie (broken packages, conflicts) > - require more regular updates to keep up with changes in > testing/unstable > - metapackaging is meant to break all the time > - always difficult to keep track of all changes that might break > an installation or make the building of the live medium > impossible. > > I am not against updating the lenny repos and move to a more sane > release/dev cycle, I think that it would also solved quite some > headaches we had (for example, how to test our packages without breaking > everyone's installations if we have only one repos for both testing and > stable). > > Also, as mentionned in the past, next coding sprint, we want to start > moving our packaging to Debian itself, so we have to adopt their release > cycle sooner or later. > > > > Any thoughts on this? > > a. > > > > > > 2009/3/31 Rob Canning <[email protected]> > > > > ok so i have recently upgraded about 4 systems > > and kept having problems due to broken packages > > every time i went aptitude install puredyne there was always some > problem. > > puredyne is a metapackage which points to lots of other packages > that > makes > > puredyne puredyne. if one of these has broken dependencies then it > wont > > install > > properly - when i tried it yesterday - 3 packages had broken > dependencies > > qsampler transcode and puredyne-processing. > > i couldnt figure out how to force puredynt just to ignore these > broken > > dependencies and do the best job it could. > > as a work around i just did an aptitude install on all the packages > except > > the > > broken ones > > > > you can see what packages are in puredyne by typing > > > > aptitude show puredyne > > > > > > i added all the packages listed here after > > > > aptitude install long list here > > > > making sure to remove the three broken packages from the list > > > > a attached a little script to this email which installs all the > packages in > > the > > puredyne metapackage > > you can remove any broken packages if you are having problems and at > least > > you > > will have 99% of puredyne > > > > its a hack but maybe will get you out of a hole until we figure out > a > > better > > way of dealing with this problem of broken packages in debian > testing > > > > claude suggested a stable puredyne metapackage? how about that? > > > > hope this helps > > > > rob > > > > -------------- > > [email protected] > > rob.goto10.org > > -------------- > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > iD8DBQFJ0gG9yHhCfi3DkcIRAq3MAJ9P0GEiP6zT/i3hSv82SuLIh56G3wCfXDi0 > > FfghwR+e9rrD/EiR7QgbTFk= > > =Qjn7 > > -----END PGP SIGNATURE----- > > > > --- > > [email protected] > > irc.goto10.org #pure:dyne > > > > > > > --- > > [email protected] > > irc.goto10.org #pure:dyne > > --- > [email protected] > irc.goto10.org #pure:dyne > > > --- > [email protected] > irc.goto10.org #pure:dyne --- [email protected] irc.goto10.org #pure:dyne
