[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Advice regarding testing



On (12/01/06 22:18), Hans wrote:
> To: Justin Pryzby <justinpryzby@users.sourceforge.net>
> Cc: debian-testing@lists.debian.org
> From: Hans <hansfong@zonnet.nl>
> Date: Thu, 12 Jan 2006 22:18:49 +0100
> Subject: Re: Advice regarding testing
> 
> Justin Pryzby wrote:
> 
> >On Thu, Jan 12, 2006 at 09:54:50PM +0100, Hans wrote:
> >>Good advice, thank you. I've been using Debian for seven years now, 
> >>mostly stable and since a year testing. My needs are not great: I can do 
> >>with stable for most packages, just the few I want fairly new (not 
> >>bleedig edge, otherwise I would install from source).
> >>
> >>I've been happy with testing, and I understand the issues with it right 
> >>now. I really want to avoid the semi-broken state it is in now once it 
> >>happens again. I will check apt-listbugs, but my fear is that once I go 
> >>up to unstable I can't go back if that gets broken (which it will, one 
> >>day). You say that you use apt-listbugs to avoid a broken system or 
> >>installing packages with criticl bugs. What is your method of pinning 
> >>them down? Using "=" in dselect? (Sorry, I am stubborn: I learned to use 
> >>dselect when I started with Debian and I'm too lazy to learn something 
> >>new. dselect just works for me, so why change? :-)

Well the advantage of using aptitude (particularly now) is that it
alerts you to broken packages and gives you a clear resolution which you
can either follow or choose to ignore.  I was formerly reluctant to
learn a new package managment system but IMHO aptitude is much better,
once you climb the initial learning curve.

When I first switched to sid, I knew very little and didn't have time to
read every open bug report (I update daily).  So I adopted a policy of
never installing packages with open bug reports; in aptitude you hold
them by pressing =.  I never got into trouble and there were fairly
short periods when certain upgrades weren't possble.  KDE3.5 recently,
for example, has taken a while for critical dependencies to be met. you
just don't upgrade until you feel comfortable.  Problems become evident
very quickly through correspondence on this list; learn from other
people's experience.
> >
> >>>On (11/01/06 22:52), Hans wrote:
> >>>     
> >>>
> >>>>For some time now many KDE-related packages are missing from testing 
> >>>>(eg. K3B, Rosegarden4, etc.). I really want to upgrade my 
> >>>>testing-system, so what is the best solution?
> >>>>
> >>>>1) pin down packages in dselect, which are going to be deleted, with =, 
> >>>>then upgrade
> >>>>2) use apt-pin and upgrade from testing/unstable 
> >>>>(http://jaqque.sbih.org/kplug/apt-pinning.html)
> >>>>       
> >>>>
> >
> >Read about apt pinning in apt_preferences(5) (really).  You can often
> >downgrade to testing, except that there are lots of library
> >transitions happening recently.  It might make sense to run testing,
> >but not update every package during such transitions.
> >
> > 
> >
> But as Clive said, mixed version systems are harder to administer. For 
> one, I tested it on an old machine and couldn't find out which version 
> of a package was installed: testing or unstable. I also couldn't see 
> clearly what an apt-get update && apt-get upgrade did: where the 
> packages from testing updated with with testing and the ones from 
> unstable with unstable, or did everything get updated from either 
> testing or unstable? I know this is me being inexperienced, and I 
> experiment a lot, but I feel I make it myself overly complicated. My 
> grail is a smart but simple solution. --Hans

It has taken me a while for me to understand apt-pinning and I have
rarely used it because I don't run a mixed system.

One other reason I run sid is to learn; when your system is changing and
unexpected things happen, it is an opportunity to learn.  And having
learnt, you can help others come to appreciate the benefits of having
real control of your computing environment.  Furthermore, from time to
time opportunties arise to contribute in a modest way to the project:
filing bug reports, helping with documentation etc.

It isn't purely an altruistic motivation because it is in my interests
for Debian to be the best OS available; all these things work towards
this.

/* sorry, steps off soapbox ...... I'll just go and have a lie down :)

Regards

Clive

-- 
www.clivemenzies.co.uk ...
...strategies for business




Reply to: