1 |
Martin Vaeth wrote: |
2 |
> Steven J. Long wrote: |
3 |
> > |
4 |
> > From what you've written, the first thing that springs to mind is |
5 |
> > /etc/portage/postsync.d/ which has q-reinitialize in it. I have that |
6 |
> > activated, and run eix-sync after emerge --sync in update, which takes |
7 |
> > care of overlays. |
8 |
> > Which answers why postsync isn't sufficient in and of itself. |
9 |
> |
10 |
> I don't understand why postsync.d is not sufficient and |
11 |
|
12 |
> why you run |
13 |
> eix-sync *after* emerge --sync (it should be run *instead of*). |
14 |
|
15 |
You don't appear to have been reading, which is odd, as the mail you got |
16 |
that info from explained the background at the same time. In summary, again: |
17 |
we wrap emerge rsync, so it only takes one line on the terminal, and then |
18 |
disappears. At the time I wrote it, I tried hard to get eix to do everything, |
19 |
believe me. |
20 |
|
21 |
Additionally,remember that I've had some people say they won't use eix (again as |
22 |
mentioned prior, though you appear to have started to address the issue in your |
23 |
more recent mail.) So irrespective of how nice eix is, we have to support users |
24 |
without it. And at the time (5 years ago) it was a lot simpler to keep the |
25 |
separation. |
26 |
|
27 |
After all, there's not much eix can do about network speed, is there? |
28 |
So what exact benefit do I get by hard-depending on eix, and losing utility? |
29 |
It's the same runtime. |
30 |
|
31 |
Don't get me wrong. I regularly sing the praises of eix, and quite often whinge |
32 |
that someone should just work with you properly, in #gentoo-portage, no doubt to |
33 |
their annoyance. But I don't code python, nor am I about to start, and you don't |
34 |
do IRC, so there's not much I can do about it. |
35 |
|
36 |
But in general we filter most of emerge's messages, in case there's something |
37 |
important like a news item, leftover config-updates, a profile upgrade, package |
38 |
moves and so on. And any message emerge spits out as IMPORTANT. Those can come |
39 |
up during sync as well. |
40 |
|
41 |
> eix-sync alone normally uses this order (only relevant tasks listed): |
42 |
> |
43 |
> 1. layman ... |
44 |
> 2. emerge --sync [ hence, followed by postsync.d hooks ] |
45 |
> 3. @-hooks from /etc/eix-sync.conf |
46 |
> 4. eix-update |
47 |
> 5. eix-diff |
48 |
|
49 |
Well we do emerge --sync, then by default run: eix-sync '-0 -N' |
50 |
|
51 |
That's changed once before, a few years ago, actually after discussion with you, |
52 |
around the metadata sync times. But I'm happy to change the default flags again, |
53 |
if you recommend something else. As is, it's always been a config setting, and it's |
54 |
up to the user to explore the wider Gentoo landscape. In this case that's the massive |
55 |
manpages for eix. |
56 |
|
57 |
If you want us to run it in a different order, that's of course fine too. I don't |
58 |
use overlays, I just like the tree diff from eix, and the speed of querying. |
59 |
Note the user can override with postSync hooks as well. If it's layman --sync for |
60 |
example, it gets run as the wrapped layman --sync command, after eix-sync. The idea |
61 |
there is that a user who is using eix doesn't set that, and instead tells eix to do |
62 |
it all, which is what we've been advising since 2007/8. But another user might. |
63 |
|
64 |
(or ofc it can be a user-defined function.) |
65 |
|
66 |
We don't shield the user from emerge: that's not update's purpose. It's designed to |
67 |
make the routine decisions easier, that belong in a higher layer, closer to the user |
68 |
and not to the package manager: ie scripted. An example of that is, we don't support |
69 |
uninstall: in a few places we just tell the user to run emerge -Cq package (like |
70 |
update -h/--help, and iirc in depclean or one of those maintenance tasks.) |
71 |
|
72 |
And to give you all the info at the time you're making a decision. But we take the |
73 |
position that dumbing-down Gentoo is a disservice to everyone: all you're doing is |
74 |
postponing the inevitable, and the user who's done their own manual install, and knows |
75 |
how and where to setup files, is much more likely to stay the distance, and be able to |
76 |
recover when the idiot-box is being an idiot. |
77 |
|
78 |
That's why coloured diffs of the relevant files are nice, since it reminds you where |
79 |
stuff goes on, at the same time as you're confirming changes. Of course, if you want |
80 |
to get complex, it'd probably take as long as trying to explain eix, given the amount |
81 |
of additions that have been put in over the years, for binhosts, tinderboxes, chroots |
82 |
etc. |
83 |
|
84 |
> so if you use postsync.d to update a local overlay according to changes in |
85 |
> the tree (or of a layman overlay) this update should be visible in eix. |
86 |
> If you do not use eix, postsync.d should do as well... |
87 |
> |
88 |
> If you want to avoid postsync.d (though I still do not understand why) |
89 |
|
90 |
Again, that's because you're reacting to certain statements without considering |
91 |
the whole. Likely because they're things that annoy you, with many of your users. |
92 |
I know the feeling ;) |
93 |
|
94 |
The simple fact is I raised postsync immediately, and was still musing as to how |
95 |
we could use it. But as you've shown above, there's a lot of stuff that goes on |
96 |
after the postsync (and overlay's have to be considered.) |
97 |
|
98 |
That's why I've always recommend our users use eix to manage their overlays. We |
99 |
wrap layman sync as well, but for end-users our advice has ALWAYS been: use eix. |
100 |
|
101 |
I have no clue where Duncan's stuff comes in as yet, and it still sounds like it |
102 |
needs reworking and QA once it's actually producing an overlay, as opposed to gobbing |
103 |
all over the local mirror. If the process can run in postsync, that would be ideal. |
104 |
As I already stated. |
105 |
|
106 |
Seriously, I'm on your side. I've personally been using eix to display the tree, and |
107 |
gladly, since the beginning. |
108 |
|
109 |
So chill out ;) |
110 |
|
111 |
-- |
112 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |