equo depends on tons of stuff.

[dagurasu]

It's probably been a few months since I updated anything. I went to install something simple, which worked, but equo mentioned that I should update it, which was probably true, so I did
equo install equo --pretend

and I get a huge list of dependancies including lots of gnome stuff, kde stuff, X stuff, even some media stuff, and a very top-level app or two (unrelated), 275 packages in all! That's not nearly my whole system, just large seemingly random bits of it, bits which certainly should not be required for the command line package manager. Is something broken on my system or is this a bug?

On a related note.. I sure wish there were still branches, but I'll make that a separate post.

[dunsurfin]

Try

Code: Select all

equo install entropy --relaxed --ask

[dagurasu]

Ok, that seems better. Thanks. I guess I'm triggering a snowball of reverse dependancies without --relaxed.

Equo example aside(or maybe not), it's one more reason why rolling release can be an even bigger pain. Anytime you want to update or install any little thing, you end up needing to update half your system, and in a realistic production environment that's not an option when you suddenly just need a small little thing, require uninterrupted usability of your computer for the short term, and don't have time to risk dealing with problems that might arise with a big update. (this happens to me routinely.. it's a normal part of my update cycle now and means I often must wait to add new things until I have time for a big update)

This is when it would be really handy to pull a package from a base release, either static or maybe just with minor fixes and security updates. Of course it requires more hard drives and probably more work to maintain that. I haven't been paying much attention lately though. Maybe static repositories do exist for the tagged releases?

[dagurasu]

By the way, what more precisely does --relaxed do? Does it ignore all reverse dependencies? Does it just omit dependency upgrades where they are available but the installed version already satisfies the dependency anyway? a and b? Does it do something more arbitrary akin to --nodeps? None of the above?

Thanks.

[wolfden]

see equo --help

--relaxed calm down dependencies resolution algorithm (might be risky)

[dagurasu]

right, relaxed = calm and relates to dependencies. I got that. I was hoping to beg a more specific answer but beggars can't be choosers either.

Anyway, I just noticed DanySK's post about frozen repositories which is now stickied. This is certainly interesting in the context of my related concern, so I will look into it.

[dagurasu]

I'm getting clues to reverse engineer my own answer here by look at the package graphs.

entropy gets pulled as a reverse dependancy on equo. rigo and rigo-daemon get pulled as reverse dependancies on entropy and magneto bits including magneto-kde get pulled as reverse deps from those. With --relaxed, that's all you get, without relaxed you then also get a bunch of forward dependancies from there, including kde stuff which snowballs, and clearly also other reverse dependancies from the kde bits including high level apps as mentioned.

So --relaxed certainly is not blocking all reverse dependencies.
I suspect what it is doing is preventing upgrades of packages where the installed version of a forward dependency technically still satisfies the dependency (and this can still be considered risky but it shouldn't be in a perfect world). This makes some sense. It's probably more risky to do that type of logic for reverse dependencies, because there is no (reliable) record of future compatibility of the reverse dependency, which I'm guessing is why the reverse dependencies are still upgraded and the forward ones are not.

[lxnay]

Awesome reply!
Yes, basically the default behavior is to avoid potential problems caused by forward dependencies still being satisfied while there are anyway updated versions.

For instance, you have app-admin/foo that you want to update, this needs >=x11-bar/baz-1.0 and you happen to have this dependency already installed (say, version 1.1) while version 1.2 is available as an update.
In this scenario, you may run into the situation where your system stops working because app-admin/foo has been compiled against baz-1.2 and the API changed while the ABI did not.
This gets even more interesting when the dependency is not at the linker level (say, python, perl, php, you-name-it, packages)

[nachoig]

Ok, that seems better. Thanks. I guess I'm triggering a snowball of reverse dependancies without --relaxed.

Equo example aside(or maybe not), it's one more reason why rolling release can be an even bigger pain. Anytime you want to update or install any little thing, you end up needing to update half your system, and in a realistic production environment that's not an option when you suddenly just need a small little thing, require uninterrupted usability of your computer for the short term, and don't have time to risk dealing with problems that might arise with a big update. (this happens to me routinely.. it's a normal part of my update cycle now and means I often must wait to add new things until I have time for a big update)

This is when it would be really handy to pull a package from a base release, either static or maybe just with minor fixes and security updates. Of course it requires more hard drives and probably more work to maintain that. I haven't been paying much attention lately though. Maybe static repositories do exist for the tagged releases?

Sabayon is a rolling release distro. Doing partial upgrades is a bad idea and should be avoided. Every Saturday the Weekly repositories are updated. Remember to upgrade your system before install something.

[dagurasu]

Thanks. As a long time user of sabayon(certainly since before it was exactly rolling release) and gentoo and... anyway, I understand more rigorous depenancy connection between binaries, although maybe my question was more inspired by my growing frustration with rolling release than my understanding of that. Anyway, yes the binary nature of a binary distribution puts more demands on having all packages from the same release obviously and rolling release means unless you snapshot a single release and keep the whole thing with you at all times, then you're stuck updating many things to today's release. Technically it's possible to do better by really tracking ABI dependancies more closely in the package management, as mentioned, but ebuild information is not enough for that (because gentoo wasn't made for that) and the work involved to add that information in entropy is probably impracticle. I'm happy taking the risky route sometimes, now that I know how it works, and since I pay attention to what packages get installed and thus know what risk I'm really taking.

Unfortunately this is the big obvious horribly nasty side effect of a pure rolling release. "Update your system before installing ANYTHING"(although it's not quite true, but close enough,.. more later) is clearly a work flow that works for fun systems (young people learning linux or more experienced folks people playing around with a non-critical box), but it's unworkable for most real use (real like you get paid for it, not real like you're willing to take the risk on tomorrow's homework grade). It's 11pm, you need some relatively minor package for some tiny but presently highly useful feature to finish your work tonight, you have meetings early in the morning and need the computer working for them.. right, reinstall ALL the software on your system right now, gauranteed to take an hour at least, possibly will break things, at least enough that you need a fresh head and 10 minutes to figure out why, possibly worse. No, that doesn't work, almost never. Even weekly, most people with personal lives can't risk an un-anticipated potential interruption to their weekend every weekend, even if it's only half an hour of "I hope I can get this fixed before 2:00". Who needs that stress? Rolling binary release is for play IMHO, not for work. Sorry to be so negative/critical. I've been a sabayon fan a long time. I like much about it, but I'll probably switch(of course I already use it some places) to the boring mainstream ubuntu when I switch my primary laptop (I don't do that often either) now. I don't mean to sound judgemental either or like one of those celebreties "threatening" to leave the country. It's free and it's good for what it is, but probably the direction it's gone and the direction I need are not as compatible as they once were. That's fine, but it's also worth making a fine point of the reasons why.

The idea of snapshot releases that emerged recently is great and I hope it gets some official traction.

It's a bit of a joke that equo still recommends to upgrade the package manager before anything else though. If it's really true that installing anything depends on having a recent package manager running and installing the recent package manager requires installing everything, then, well that's clearly the joke. Fortunately I've never hit an actual problem with that, but the warning is still a bit humorous.


Now back to pick on your overly generalized claim. I would say that's just wrong. If you have a dep tree like this:

Code: Select all

A    B     C
 |   |     |
   D       E
     |    |
        F


Where F is the kernel or whatever and A B and C are applications.
If you have everything but A installed and updates are available for D B and C but not F or E and you ask to install A you will pull updates for D and B, and C will be left alone even though there is an update, and you will have no problem since C doesn't care at all about anything that has changed. In most normal situations if everything works right, just doing the install of A should take care of this just fine without updating "your system". This can be especially important if there is one high level package that you depend on for work that does not require upgrading. Of course you rarely get that lucky, but I have made MANY install triggered upgrades to large fractions, but not all, of my system without problems.