Loz said : > I have to say, that sticking with stable on Debian is a bit of an > overkill, in my opinion. Debian stable is possibly the most > bulletproof an operating system is going to get, but do you really > need that? Testing seems the most sane thing to follow. I'd equate the > stability and newness of Debian testing with milestone releases of > other Linux distros. I've certainly had no major issues on my Debian > system sticking with testing. Which is more than can be said for SuSE > or Fedora.
I agree that testing is really reliable. pure:dyne live relies on testing and unstable (via pulling) and it's fine most of the time. The only time I shot myself on the foot was by doing pining from experimental, then things start to be more difficult to follow. So far it has proven to work very well, except for metapackaging because dependencies are spread over 3 different testing repos, so it's just bound to break at some point. But now, If someone uses the live version running of a stick, or a hd. Everything is fine, until this person decides to update the liveUSB/HD via aptitude. Then, instead of pulling just some files related to the audio/video/multimedia software, it might pull a whole new system that will have to be cached on the persistent mode, and might also just break the system. Erasing the stick or the HD with a new liveUSB/HD recent snapshot would be then easier, which breaks a bit the concept of a live system that can be maintained with minimal effort. Could we imagine that the base system is lenny with some pining on testing and unstable + some backports? If someone would like to have a full install, then the same pining could be applied..? > Debian's release schedule means that sticking to stable would most > likely cause the death of p:d, as it would be pretty out of date > within a few months, and people would move off onto other > multimedia-based distributions, if only for proper support for newer > hardware and new features. In your opinion, which components that would become outdated, would be a real problem? As Ricardo pointed out, we might not need to have the full system at the latest version as long as the important bits are kept up to date. Most of hardware issues would be resolved by kernel upgrades, and a few packages would need particular attention like alsa or xorg if we want to support latest changes and improvements for recent hardware. Also I believe (I might be wrong) that pure:dyne users are not into full blast desktop eyecandy (compiz for example) that often means that the system must be kept to a very fresh version. I believe that most of us, just want a system that is fast, responsive and has recent enough versions of all kind of "artistic" software, and not some bleeding edge fancy desktop... Of course, I say that, but right now I'm using xorg from experimental because I wanted to try the new liddrm2 ... *cough* :) But I suppose that this could probably all be handled by some clever pining directly from lenny ... Sorry for the blabla, but I think we need to clarify all this before we head right into the next working session, better talk things through first.... a. > Loz > > On Tue, Mar 31, 2009 at 5:20 PM, jm jones <[email protected]> wrote: > > 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 > > > > --- > [email protected] > irc.goto10.org #pure:dyne > --- [email protected] irc.goto10.org #pure:dyne
