| 1 |
On Sat, 26 Sep 2015 15:10:48 +0200, lee wrote: |
| 2 |
|
| 3 |
> It seems that everyone has the problem that some versions of some |
| 4 |
> packages don't go together with some versions of other packages the |
| 5 |
> 'some versions of some packages' depend on. |
| 6 |
|
| 7 |
That's just life, and 99% of th time it either doesn't matter or is |
| 8 |
handled by slots. A and B depend on C. A new version of C comes out but A |
| 9 |
can't work with it, so portage doesn't update it. B is still happy because |
| 10 |
it always worked with the older C, portage just tells you why it hasn't |
| 11 |
updated C. |
| 12 |
|
| 13 |
> Then emerge comes along and points this out as an extremely serious |
| 14 |
> problem while all it takes to solve this problem is someone convincing |
| 15 |
> the person observing what emerge does that the apparently serious |
| 16 |
> problems aren't relevant at all. |
| 17 |
|
| 18 |
It didn't say it was serious, although the overuse of exclamation marks |
| 19 |
could be seen as implying that (I have an automatic exclamation mark |
| 20 |
filter, so I don't really notice them). |
| 21 |
|
| 22 |
> So who is at fault here? The user taking emerges warnings seriously |
| 23 |
> because they don't want to break their system, or emerge by making |
| 24 |
> irrelevant warnings appear as being so serious problems that the |
| 25 |
> unsuspecting user gets so confused and scared of breaking their system |
| 26 |
> that they start to ask questions on mailing lists? |
| 27 |
|
| 28 |
The problem is that portage does not clearly distinguish between |
| 29 |
information, warnings and error messages. The simplest way of looking at |
| 30 |
it is "does this stop the emerge proceeding". In your original case, |
| 31 |
that was not the case. The emerge did stop, but because of the thing |
| 32 |
with hdf5 and the threads USE flag. Once you had cleared that, the |
| 33 |
emerge would most likely have proceeded despite the messages. |
| 34 |
|
| 35 |
> > quickpkg is really quick. |
| 36 |
> > Then, to reinstall from that: emerge -vak1 dev-libs/boost |
| 37 |
> |
| 38 |
> Oh, it's the whole updating thing. Besides a chance that I'll have to |
| 39 |
> fix something, it also brings in a new kernel to make and to install. |
| 40 |
> That takes time. |
| 41 |
|
| 42 |
Only if you do it. Unless your existing kernel has stopped working, why |
| 43 |
the rush to build a new one? |
| 44 |
|
| 45 |
> > The more freedom with the package manager, the more conflicts you |
| 46 |
> > might encounter. |
| 47 |
> |
| 48 |
> That doesn't mean that the package manager should be unable to provide |
| 49 |
> the user with a number of possible solutions and let them pick one. |
| 50 |
|
| 51 |
It did, it told you to add one USE flag or remove another. |
| 52 |
|
| 53 |
> Particularly, it doesn't mean that the package manager should give the |
| 54 |
> impression that things might go horribly wrong when some action is |
| 55 |
> performed unless they actually will. |
| 56 |
|
| 57 |
No, it shouldn't. But it is already well established that portage's |
| 58 |
output can be opaque from a user's perspective. That's a well trodden |
| 59 |
path that is not worth revisiting unless you can help with a solution. |
| 60 |
|
| 61 |
> >> Where and how do the above messages give me choices? They are |
| 62 |
> >> telling me that boost doesn't work with itself, |
| 63 |
|
| 64 |
No they aren't. They are saying that boost will not be upgraded, they are |
| 65 |
not saying that anything will not work. I've been seeing almost identical |
| 66 |
messages about ocaml for months now, things still work with the version I |
| 67 |
had before the messages began. |
| 68 |
|
| 69 |
> > There is, several in fact. |
| 70 |
> > One is called "Backups" |
| 71 |
> |
| 72 |
> You seriously expect a backup just to be able to undo an emerge --sync? |
| 73 |
|
| 74 |
Absolutely. All sync does is update the contents of a directory, if you |
| 75 |
backed up that directory you could restore it. |
| 76 |
|
| 77 |
> Ok, then make it as easy to boot from ZFS as it is to boot from ext4. |
| 78 |
> |
| 79 |
> On a side note, how difficult or easy, and how advisable, is booting |
| 80 |
> from btrfs, particularly for a xen PV guest which might have the kernel |
| 81 |
> residing on the host? (I might prefer that over using lvm.) |
| 82 |
|
| 83 |
I don't know about Xen, but on real hardware it's as simple as ext4 with |
| 84 |
a single drive, and transparently handled by dracut if you use RAID. |
| 85 |
|
| 86 |
> > The other one is portage snapshots. |
| 87 |
> |
| 88 |
> That sounds like something I should learn about. |
| 89 |
|
| 90 |
See above re backups, it's just a tarball of the portage tree. |
| 91 |
|
| 92 |
|
| 93 |
-- |
| 94 |
Neil Bothwick |
| 95 |
|
| 96 |
But there, everything has its drawbacks, as the man said when his |
| 97 |
mother-in-law died, and they came down upon him for the funeral expenses. |
| 98 |
-- Jerome K. Jerome |
Archives