Re: Gnome totally broke
On Sat, Apr 21, 2001 at 07:54:15PM -0700, Thomas Bushnell, BSG wrote:
> Anthony Towns <aj@azure.humbug.org.au> writes:
> > On Sat, Apr 21, 2001 at 03:09:28PM -0700, Thomas Bushnell, BSG wrote:
> > > Some of the packages migrated into testing depend on the non-migrated
> > > packages. Those packages cannot be installed:
> > Cite.
> Forgive my inaccuracy; the problem may be that certain packages were
> entirely removed from testing; this is just as bad, but doesn't match
> my description. When fixing my system, my priority was on getting it
> working and not on keeping records of the process.
Which is entirely reasonable, but not much of a justification for messages
entitled ``Gnome totally broke'' and declaring that ``testing is once
again thoroughly hosed''. Is a little decorum too much to ask?
> Here's one example that I know for certain. I had task-gnome-apps
> installed. That package exists in potato and sid, but not woody. It
> did once exist in woody, but got removed.
task-gnome-apps depends on task-gnome-desktop, which was also
removed, due to its dependency on gnome-faq, which no longer exists, and
that gnome-applets no longer makes it in.
> task-gnome-apps depends on gnome-admin. The latter package exists in
> potato and sid, but not in woody. But it did once exist.
task-gnome-apps no longer exists either. I'm quite sure apt would've
told you about this, at which point you had the opportunity to put the
appropriate packages on hold, or remove inappropriate packages.
> Attempting to do "apt-get install gnome-panel" downloads the new
> gnome-panel, but then produces irreconcilable conflicts.
"irreconcilable" ? I can assure you, they're quite reconcilable: as
evidence I proffer the fact that I'm running Gnome from testing right now.
If you're claiming that the Gnome dependency information isn't correct,
then you'll need to give some actual information if you want it fixed.
What packages, what were the error messages, etc.
bash: Fmt: command not found
> In an environment that has dependencies, you simply cannot safely
> remove packages from the archive without carefully considering the
> whole context.
I can assure you, you can: that's the entire point of dependencies, that
a user will at least be warned before they try installing packages whose
dependencies can't be met, or which conflict with other packages they have
installed. Both dpkg and apt will tell you about these things before you
do anything, if you choose to ignore their warnings, or press on regardless,
well, too bad for you.
You seem to be mistaking `testing' for `stable'. It's not. The goals
of stable are significantly stricter than the goals of testing. If you
follow testing you mightn't get surprises like an upgrade of bash or grep
suddenly making one of those tools not work or similar, but you will
find functionality you previously had disappear and reappear, you will
find annoying bugs and so forth. You can't just fire and forget, like
you generally can with stable. `testing' is *not* a silver bullet. It
doesn't magically make all your problems go away forever. There's still
a need for quality assurance and testing and freezing and so forth.
And if you'd like to go back to basing the release on `unstable', well,
that's easy: it's still there afterall.
If you're actually interested in fixing stuff and making the next stable
release better, you'll want to be a lot more specific (whether you're
less hyperbolic or not) than you've been so far though.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Reply to: