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

Re: Gnome 2.10 going in to etch today



On Tue, Sep 13, 2005 at 09:28:46AM -0500, Jason Clinton wrote:
> On Tuesday 13 September 2005 12:21 am, Marc Wilson wrote:
> > Because the whole reason the "gnome-desktop-environment" *meta-package*
> > exists is to give you a complete Gnome.  Not Gnome minus whatever *this*
> > cluebie doesn't like, whatever *that* cluebie doesn't like, etc.
> >
> > If you don't like what the meta-package installs, don't use the
> > gods-be-damned thing.  Install one of the sub-packages, install whatever
> > parts of Gnome float your boat.  The dependencies of the meta-package tell
> > you what they all are.
> 
> I think you intentionally misunderstand what he's saying. He's saying that 50% 
> of the gnome desktop shouldn't be removed by aptitude because one packages is 
> missing from the "gnome experience" metapackage. And maybe it shouldn't have 
> even moved in to testing if a dependacy wasn't met?

Aptitude has known breakage in this area.  Easy solution... don't use
aptitude.  Better still, learn the difference between an upgrade and a
dist-upgrade.  The *only* way that packages can be removed is if you allow
them to be.

> It is not possible to do what you claim. The only way to get the subcomponents 
> in to your system is to mark them as manual installs.

What does the term "manual installs" mean?  If you mean what I think you
mean, why is that a bad thing?  A bad thing to *aptitude*, I can well
imagine... it generally falls over at the first sign of trouble.

> And even then other fundamental Gnome components won't installed because
> the gnome-multimedia metapackage conditions aren't met.

The *only* reverse-depends of the sound-juicer package is
gnome-desktop-environment.  I have no idea what this "gnome-multimedia"
meta-package you're talking about is... it doesn't exist in stable,
testing, or unstable.

Please describe the "Gnome multimedia" packages that will not be installed.
Why they will not be installed would be better.  "Because aptitude can't
handle it" is not an acceptable answer.

> You seem to fundamentally misunderstand the complexity of gnome
> intradependacies. Sound-juicer not being present forces aptitude to
> remove approximately 50% of Gnome to avoid unmet dependacies.

Nonsense.  Again, sound-juicer's *only* rdepends is the desktop-environment
package.  Anything else is aptitude breakage.  Reference bugs #200415,
#212164, #213106, #235727, #237830, #299009, #316027, etc, etc, etc.
Aptitude needs some *serious* bug triage before it should be at all
trusted.

The biggie, of course, being #299009.  Not that it's the only bug # that
reports the same issue.

So, again, please describe the unmet dependencies.  What packages depend on
sound-juicer?
 
> Further, marking packages as manual installs when you later intend to use the 
> metapackage to track upgrades is a bad idea. Finding all the packages you 
> marked as 'manual' and remarking them as 'auto' is no simple task.

I'll freely admit I've avoided aptitude like the broken POS that it is for
a very long time, so I may not be up on its "invented-here" terminology.
Are you actually saying that if you install a package, aptitude will not
upgrade it, even if a new version is available?  I have no idea at all what
you intend the statement "use the metapackage to track upgrades" to mean.

> > Oh, wait... that would mean you'd actually have a clue about what testing
> > is, wouldn't it?
> 
> This was rude and unnessary. And it seems that he understands what testing is: 
> a testing ground for canidates for "stable".

You may, but he doesn't.  

> > > Why should I *have* to install sound-juicer?
> >
> > You don't.  See above.
> 
> You do or several things won't install.

Really.  A list would be nice.

> > > And this same question applies to a lot of other packages. Often if I
> > > try to upgrade a bunch of stuff, ...
> >
> > <snip OP describing his misunderstanding of how updates work>
> >
> > Why don't you just stick to stable, huh?

> Because stable is too old for a desktop. And unstable is too new for a 
> desktop. Testing is just right (usually).

I get SO tired of that particular bit of crap.  "Too old" is a meaningless
statement.  Now, if you want to describe things you need to do that you
can't do, I'm listening.  But software does not come with an expiration
date.  The fact that something is not the latest by that
all-important-chased-by-cluebies 1/100th of a version number does not
somehow make it stop working.

-- 
 Marc Wilson |     Oh, I am a C programmer and I'm okay I muck with
 msw@cox.net |     indices and structs all day And when it works,
             |     I shout hoo-ray Oh, I am a C programmer and I'm okay

Attachment: signature.asc
Description: Digital signature


Reply to: