Hi, Andrew
(I am not very knowledgeable on this issue, so bear in mind.)
New version states "apt pinning, to ease partial upgrades to our testing
branch" which I think is a fair statement. It _eases_ partial upgrades
but does not solve all the possible issues.
Before starting to discuss details, let me say tracking "testing" right
after a new major releases/changes with any methods is "playing with
fire". It is fun but it may burn you. I got burned previously and
learned how to handle it gracefully in hard way.
See my item-by-item responses below for the details.
On Sun, Apr 28, 2002 at 08:29:22AM -0400, Andrew Pimlott wrote:
> On Sat, Apr 27, 2002 at 07:53:06PM -0700, Osamu Aoki wrote:
> > I tend to pin some essential files to safer distribution while allowing
> > to access to other branches.
> >
> > libc6. Always choose safest one as default.
> > Manually upgrade to known good ones.
> > gnome-* Latest.
> [...]
> > I think dselect accessed through apt-method honors pin scores and
> > provides the best score one as the choice. You just do not see all the
> > alternative versions with pin scores. It may not be best you hope for
> > but very functional and useful for me.
>
> Assume for this example that you pin libc6 to testing, and gnome-*
> to unstable.
Yes. That was what I was until yesterday :)
> Say you want to install a new gnome-* package, whose unstable version
> requires a newer libc6 than is in testing.
Well my expectations are set as follows for this kind of situation:
1. start "dselect update && dselect select"
2. press "+" at "a-new-gnome-*-package" and "Enter"
3. dselect blurbs major removal suggestions which may even remove
"libc6". (This is not a big deal in testing/unstable since it happen
before even without _pin_. After all this is not _stable_.)
4. Say "shoot", hit "R" for revert, hit "D" for dammit, hit "Q" for
quit, and curse at user interface of "dselect" :)
So nothing happens since nothing is done and I go to sleep. I can not
expect more.
"Complicated?", yes. "Fun?", yes too. That was the reason I started
writing "Debian reference".
http://www.debian.org/doc/manuals/reference/
By the way, if the same kind of situation hits us within pre-selected
packages and we have to upgrade system for some other packages at that
moment, press "=" to _hold_ the problematic package and proceed. Of
cause, before our flaky memory goes out after this upgrading, run
"dselect select" and put back all the _hold_(=) to _install_(+) and do
not run "dselect install" and go to sleep. Then happily live with
"dselect". We can always find _hold_ packages by running "dpkg
--get-selections | grep "hold$" | less" if we forget.
Even if you were tracking only testing or unstable, similar problems
used to happen. For example, until recently, "mozilla" upgrade had
caused dependency issues with "galeon" for few days. Best solution used
to be "sleep tactics" for me :) But in some cases I used to do above
routine operations of _hold_.
> You can't do it in dselect, can you? You have to drop to apt-get and
> install the testing version ("apt-get -t testing"). But as soon as
> you go back into dselect, it will break again (trying to upgrade to
> unstable), so you have to put it on hold.
As I said above, if I were desperate to upgrade for resolving some
issues, "apt-get -t testing" is not required. I have to admit that I
may have done this for the ease of operation. It has been more or less
"apt-get -t unstable" or "dpkg -i package-from-incoming.deb" in my real
situation. Anyway, this situation is along my expectation level and not
a problem :)
> This will even prevent you from upgrading to newer testing versions
> (you will not even see that newer testing versions are available), so
> you would have to go back to apt-get for that.
As long as you do not forget to release _hold_ and remember to speak
the "D" word to the "dselect", it is fine.
> And there is no way to know when to remove the hold (to upgrade to
> unstable, when possible), except by trying it and seeing when it
> doesn't break. When another unstable version that requires unstable
> libc6 comes along, it breaks again ...
If you follow my tactics, situation is different:) You get reminded that
you have dependency issues at all times when you wish to upgrade.
Annoying, yes. But that is testing/unstable anyway.
In case of "testing & unstable combination", it get resolved eventually
with time. If this is "stable & testing combination", some manual
operation is needed. I usually download a package from testing without
installing them and go to sleep. Next day, I check mailing list for
the major issues. If no problem, "dpkg -i package-from-testing.deb".
> Am I right about this, or do you have a better way?
I do not know above is "better" but quite useful for me to track
unstable without hitting major issues with some basic packages. I think
tracking pure _unstable_ is too much for fun. That's why I do this and
appreciate _pin_ :)
Have fun upgrading.
Osamu
--
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +++++
Osamu Aoki @ Cupertino CA USA
See "User's Guide": http://www.debian.org/doc/manuals/users-guide/
See "Debian reference": http://www.debian.org/doc/manuals/reference/
"Debian reference" Project at: http://qref.sf.net
I welcome your constructive criticisms and corrections.
Attachment:
pgpXJ68l3cFBo.pgp
Description: PGP signature