[pure:dyne] problems updating puredyne?

[jm jones]

2009/3/31 Aymeric Mansoux <aymeric at goto10.org>:
> 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 <rob at goto10.org>
>>
>>     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
>>
>>     --------------
>>     rob at goto10.org
>>     rob.goto10.org
>>     --------------
>>
>>     -----BEGIN PGP SIGNATURE-----
>>     Version: GnuPG v1.4.6 (GNU/Linux)
>>
>>     iD8DBQFJ0gG9yHhCfi3DkcIRAq3MAJ9P0GEiP6zT/i3hSv82SuLIh56G3wCfXDi0
>>     FfghwR+e9rrD/EiR7QgbTFk=
>>     =Qjn7
>>     -----END PGP SIGNATURE-----
>>
>>     ---
>>     Puredyne at goto10.org
>>     irc.goto10.org #pure:dyne
>>
>>
>
>> ---
>> Puredyne at goto10.org
>> irc.goto10.org #pure:dyne
>
> ---
> Puredyne at goto10.org
> 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