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 >
I think that in a working enviroment we need a stable system. And figure out how to resolve the cons. -- JM --- [email protected] irc.goto10.org #pure:dyne
