On 15-Jun-09, at 11:51 PM, Andreas Tille wrote: (BTW, it is helpful to track down your apt_pinning settings as well)
yes, as per solution pointed out by Rogerio, which I had only previously partly implemented - duh!
but rather try: apt-get -t testing install gnumed-client
I updated the related wiki page and only wonder, if the above is used on a machine where main is the 'stable' distribution, then will the fact that gnumed-client was taken from 'testing' be respected the next time the user tries to apt-get update? Or is the user likely to be presented with a dependency mismatch that (each time) will need
apt-get -t testing install gnumed-client
Provided that enough gnumed dependencies are included in the pinning, it seemed to me pinning (once properly set up) could be the lower maintenance solution since it is still not clear to me how well Synaptic Package Manager supports mixed systems where that is what we would get a more-newbie-than-me user to employ (notwithstanding Lenny's SPM had a bad bug, at least some months ago)
1) packages that were uploaded into experimental stay there, perhaps until someone makes a changelog entry instructing approval that it can move to a new target distribution... this can be a required delaying tactic when some other package having the same name (like a lower-numbered version of gnumed-server) is still sitting in unstable waiting to move into testing
2) packages that enter the unstable distribution (whether by direct upload or by passing from experimental into unstable) spend at least 14 days there for evaluation before passing into testing as per a non-maintainer upload (NMU) protocol.
Correct except that there is only one chance to go to unstable - by direct upload. There is no way to pass from experimental to anywhere else. And NMU is no protocol. It just marks those uploads who were not done by the package maintainer but by somebody else. This is an exception in case of burning reasons (and IMHO never happened for gnumed packages). All good to know, thanks.
|