"J. Roeleveld" <jo...@antarean.org> writes: > On Sunday 20 September 2015 16:25:34 lee wrote: >> Alan McKinnon <alan.mckin...@gmail.com> writes: >> > On 19/09/2015 21:36, lee wrote: >> >> Hi, >> >> >> >> how could I solve these updating problems: >> >> >> >> >> >> emerge -j 8 -a --update --newuse --deep --with-bdeps=y @world >> >> >> >> * IMPORTANT: 4 news items need reading for repository 'gentoo'. >> >> * Use eselect news read to view new items. >> >> >> >> These are the packages that would be merged, in order: >> >> >> >> Calculating dependencies... done! >> >> >> >> !!! Multiple package instances within a single package slot have been >> >> pulled !!! into the dependency graph, resulting in a slot conflict: >> >> >> >> dev-libs/boost:0 >> >> >> >> (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge) >> >> pulled in by>> >> >> (no parents that aren't satisfied by other packages in this slot) >> >> >> >> (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge) >> >> pulled in by>> >> >> dev-libs/boost:0/1.55.0= required by >> >> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)>> >> >> ^^^^^^^^^^ >> >> >> >> (and 2 more with the same problem) >> > >> > I'm not sure why you are getting this one. Portage is only pulling in >> > boost-1.56.0-r1 because it's the latest stable version, but librevenge >> > requires something earlier. Portage should therefore shut up and install >> > the only real solution - keep boost at 1.55.0 >> >> Maybe because it says that there's a slot conflict. I had another one >> of those, and getting rid of it prevents me from having a pdf reader >> installed. I haven't had the need to read a pdf since, but sooner or >> later I'll need to be able to. > > Can you provide your world file? > should be located at: > /var/lib/portage/world
world.bz2
Description: BZip2 compressed data
The pdf problem was with mupdf blocking some library, so I removed
mupdf. However, llpp still works while I thought it required mupdf, so
that was false information. Sorry about that noise.
>> > Try these possibilities:
>> >
>> > emerge =dev-libs/boost-1.55.0-r2
>>
>> Why this particular version; how did you figure that out? I read from
>> the second message that boost doesn't work with itself because
>> librevenge is installed. So I could remove librevenge, but a lot of
>> things depend on it, amongst them libreoffice.
>
> Don't forget to add "-1" or "--oneshot" as options when installing
> dependencies manually.
ok
>> From there, I don't know what the effects are. Now libreoffice is still
>> 4.4.1.2, and I would expect it being upgraded to 5.x maybe. So I would
>> have to remove boost instead --- IIRC I installed it only to try out
>> regex_match() and regex_search() --- but removing boost seems a bit
>> unreasonable, considering that it takes a while to build. And even with
>> boost removed, I have no good reason to think that there won't be other
>> problems, and it leaves the question what to do when I need boost again:
>> I don't even have a pdf reader ...
>>
>> So I decided I'd better ask what to do. It's hard to believe that we
>> are seriously expected to remove lots of software which we might not be
>> able to install again just to do an update. All these conflicts give me
>> the impression that something in the repo is broken and needs to be
>> fixed.
>
> I have no such issues, neither do most people.
> Which seems to indicate the issue is not with the repo.
> Lets look at the actual contents of your world-file. (see above)
It seems that everyone has the problem that some versions of some
packages don't go together with some versions of other packages the
'some versions of some packages' depend on.
Then emerge comes along and points this out as an extremely serious
problem while all it takes to solve this problem is someone convincing
the person observing what emerge does that the apparently serious
problems aren't relevant at all.
So who is at fault here? The user taking emerges warnings seriously
because they don't want to break their system, or emerge by making
irrelevant warnings appear as being so serious problems that the
unsuspecting user gets so confused and scared of breaking their system
that they start to ask questions on mailing lists?
After all, that's what the smart user does while the not-so-smart users
break their systems all the time and never learn from their experiences.
>> > emerge -avuND world
>> >
>> > or
>> >
>> > emerge -j 8 -a --update --newuse --deep --with-bdeps=n @world
>> >
>> > or quickpkg boost, then unmerge it and re-run emerge world.
>> > Boost is a pain to build so with a quickpkg you can put it back with a
>> > minimum of effort
>>
>> Maybe next weekend or so, I don't feel like doing it now and don't
>> really have the time to.
>
> quickpkg is really quick.
> Then, to reinstall from that: emerge -vak1 dev-libs/boost
Oh, it's the whole updating thing. Besides a chance that I'll have to
fix something, it also brings in a new kernel to make and to install.
That takes time.
Compiling stuff doesn't bother you when you have 24 cores and 48GB. You
don't even notice other than that the fans may run a little faster.
> [...]
>> >> !!! The ebuild selected to satisfy "sci-libs/hdf5" has unmet
>> >> requirements.
>> >> - sci-libs/hdf5-1.8.14-r1::gentoo USE="cxx fortran threads zlib -debug
>> >> -examples -fortran2003 -mpi -static-libs -szip">>
>> >> The following REQUIRED_USE flag constraints are unsatisfied:
>> >> threads? ( !cxx !fortran )
>> >
>> > Come on, the problem is as clear as daylight and stated right there in
>> > the output:
>> >
>> > If you have threads in USE for hdf5, then you cannot have cxx and/or
>> > fortran also in USE for hdf5
>> >
>> > echo "=sci-libs/hdf5-1.8.14-r1 -cxx -fortran" >>
>> > /etc/portage/package.use/package.use
>>
>> I gathered that much, but I didn't feel like trying to find out whether
>> it's better to disable threads or cxx and fortran because of the other
>> problems. hdf5 was pulled in because of dependencies and not because I
>> installed it, so I didn't check its USE flags to begin with.
>
> Keep threads if you want performance.
> Then again, what do you want to do with hdf?
heimdali ~ # equery d hdf5
* These packages depend on hdf5:
media-libs/openimageio-1.3.5 (sci-libs/hdf5)
heimdali ~ # equery d openimageio
* These packages depend on openimageio:
media-gfx/blender-2.72b-r3 (cycles ? media-libs/openimageio)
(openimageio ? media-libs/openimageio)
>> >> I could remove boost (and maybe reinstall it later), but I would like to
>> >> keep ffmpeg. hdf5 apparently goes back to having blender installed,
>> >> which I would also like to keep. And apparently, I would have to remove
>> >> libreoffice before I could update.
>> >
>> > What does libreoffice have to do with this?
>>
>> It depends on librevenge.
>
> world-file?
above
> [...]
>> > This is because of how Gentoo works. With a binary distro, there is only
>> > one variant of a package. If package A depends on ldap, and cifs, and
>> > kerberos and nfs, and you don't want any of those then that is tough
>> > shit because you are going to get them. And you are going to get them
>> > because the package maintainer said you are going to get them.
>>
>> That's one of the things that bothers me with binary distributions.
>
> The more freedom with the package manager, the more conflicts you might
> encounter.
That doesn't mean that the package manager should be unable to provide
the user with a number of possible solutions and let them pick one.
Particularly, it doesn't mean that the package manager should give the
impression that things might go horribly wrong when some action is
performed unless they actually will.
>> > Gentoo gives you the choice, and sometimes your choices interfere with
>> > other choices you make. Now you get to decide.
>> >
>> > Binary distros run into the same problems as above, and the package
>> > maintainer has to solve them. When that is done, the package gets pushed
>> > out and you don't see what it took. You also don't have any choice.
>> >
>> > In Gentoo, YOU have the role that a maintainer has on Fedora, YOU get to
>> > find out how to solve the problem and YOU get to implement it. That is
>> > the inevitable side-effect of having choice.
>>
>> Where and how do the above messages give me choices? They are telling
>> me that boost doesn't work with itself,
>
> It does, just not versions that are too close and would end up overwriting
> each others files.
They are apparently trying to tell me that things will go horribly
wrong. They are speaking of "slot conflicts" and use a bunch of
exclamation marks to point out the importance.
WTH is a "slot conflict"? I can guess what that is, and I can speculate
about what might happen. One of the possibilities that come to mind is
definitely *not* what I would want.
It would be nice if the messages were simply telling me what's actually
going on and what emerge would actually do. Perhaps this is one of the
cases in which the programmer hasn't considered the user. For the
programmer, these messages might be totally clear because they know what
they mean. They aren't clear for the user because the user doesn't know
what they mean. That is so because the messages don't tell the user
what they mean. The solution is simple: replace messages with messages
that tell the user what's going on.
The programmer might think that's a bad solution because they want to
improve the package manager in some great way so that it can solve all
problems, and implementing the solution requires a lot of work and time.
Unfortunately, that isn't very practical because until the great
solution is implemented, the users remain confused. So in the meantime,
why not simply improve the messages --- and perhaps it turns out that
the great solution isn't even required because the users just solve the
problems themselves. Users have a way of doing that, and not seldwhen,
they find unexpected ways which would never occur to a programmer.
> [...]
>> My conclusion is that something in the repos might be broken because if
>> it wasn't, I wouldn't have these problems.
>
> I'm thinking world-file..
You think it's broken? If so, how might that have happened?
>> So my choices are to try to somehow force an upgrade and be left with a
>> non-working system, or to wait until the problems are fixed, or to ask
>> for help.
>
> force an upgrade?
Yeah, I don't know, there's probably some way to force ignoring
dependencies or something.
If there's not, well, I do have physical and root access, so I can do
anything I want. That's how I messed up my first Linux installation
over 20 years ago, by changing file permissions beyond the point of
repair because it won't let me create a file where I wanted it and I
didn't know any better. So I finally created the file, and the next
moment, I suddenly learned about file permissions and figured I better
reinstall. I suppose for intelligent people, their own stupidity is the
kind most painful.
It was a good learning experience, though. Ever since, I never was
forced to reinstall until I recently found out that xen with HVM cannot
be done on a non-multilib Gentoo (which I still think is stupid and
should be fixed). Talk about the unexpected ways of programmers now ...
>> Asking for help turns out that I don't really have a choice because I
>> can either try to somehow force an upgrade and take the risk of being
>> left with a non-working system (because Gentoo gives me choices: perhaps
>> you can see the irony here), or not upgrade at all.
>
> How would you force an upgrade?
I don't know, I don't want to do that, so I haven't looked into it. I
want to do it right, that's why I'm asking here.
>> >> What do I do when I need to update /right now/ and find myself being
>> >> blocked with cryptic messages like the above that leave me stranded?
>> >> Once I used 'emerge --sync', there is no way to turn it back to continue
>> >> to be able to install software if needed when the update cannot be
>> >> performed. Updates simply need to work, there's no way around that.
>> >
>> > You seem unwilling to do what it takes to run Gentoo properly. I suggest
>> > you delete your Gentoo systems and install Fedora instead. Gentoo is
>> > obviously not for you.
>>
>> That is a really wild assumption you're making, to put it nicely.
>>
>> Besides, IMO Fedora is run by stupid fascists who believe they can
>> dictate people what to think and take over the world --- which is
>> something I don't want to have anything to do with --- and I don't want
>> systemd, either, which appears to come along remarkably similar lines.
>> You'd have to suggest a better alternative, one that is better than
>> Gentoo.
>
> It depends, for someone who wants it all to work magically?
> Or for someone who doesn't mind learning?
What, Fedora? It's much like windoze, in that it works only as long and
as much as it does, though better, and when you have something that
doesn't work or want something to work the way you want or need it to,
you're screwed.
If you're fine with that and don't mind their attitude, and if you like
what you get presented with, go Fedora, if you can get past the
installer. Everything aside, they do make a good distribution --- which
seems to be greatly underrated, or a lot more people would use it,
especially on laptops.
Updates with Fedora don't always magically work, though. There have
been quite a few occasions when the nvidia drivers were broken in the
repo. So I suppose you can't use that, either.
Look at my world file; you'll see that I'll never be the kind of user
Fedora would be particularly attractive to, especially not out of the
box.
>> Other than that, can't you imagine that there might be room for
>> improvement? Like a way to undo an 'emerge --sync' and messages that
>> are more informative, or providing the user with actual choices that
>> would solve the problem and let them decide which solution they want
>> (think of aptitude, which Debian has)?
>
> There is, several in fact.
> One is called "Backups"
You seriously expect a backup just to be able to undo an emerge --sync?
Ok, then make it as easy to boot from ZFS as it is to boot from ext4.
On a side note, how difficult or easy, and how advisable, is booting
from btrfs, particularly for a xen PV guest which might have the kernel
residing on the host? (I might prefer that over using lvm.)
> The other one is portage snapshots.
That sounds like something I should learn about.
>> Or would you rather say that Gentoo seems unwilling to do what it takes
>> to make it easier to upgrade? Yeah, I know, developer resources are
>> limited, but so are mine.
>
> Mine are even more limited, but I manage to upgrade multiple machines
> regularly (on average once every 2 months the whole lot)
Perhaps that's because you've already gone through all the required
learning, having used Gentoo for a long time. Not everyone has arrived
there yet. That doesn't mean everyone is unwilling to learn, or to go
to extreme lengths to use Gentoo.
--
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us. Finally, this fear has become reasonable.
