[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-desktop
Subject:    [gentoo-desktop] Re: kde-lean overlay
From:       "Steven J. Long" <slong () rathaus ! eclipse ! co ! uk>
Date:       2013-07-18 19:30:33
Message-ID: 20130718193033.GA9361 () rathaus ! eclipse ! co ! uk
[Download RAW message or body]

Martin Vaeth wrote:
> Steven J. Long wrote:
> >
> > From what you've written, the first thing that springs to mind is
> > /etc/portage/postsync.d/ which has q-reinitialize in it. I have that
> > activated, and run eix-sync after emerge --sync in update, which takes
> > care of overlays.
> > Which answers why postsync isn't sufficient in and of itself.
> 
> I don't understand why postsync.d is not sufficient and

> why you run
> eix-sync *after* emerge --sync (it should be run *instead of*).

You don't appear to have been reading, which is odd, as the mail you got
that info from explained the background at the same time. In summary, again:
we wrap emerge rsync, so it only takes one line on the terminal, and then
disappears. At the time I wrote it, I tried hard to get eix to do everything,
believe me.

Additionally,remember that I've had some people say they won't use eix (again as
mentioned prior, though you appear to have started to address the issue in your
more recent mail.) So irrespective of how nice eix is, we have to support users
without it. And at the time (5 years ago) it was a lot simpler to keep the
separation.

After all, there's not much eix can do about network speed, is there?
So what exact benefit do I get by hard-depending on eix, and losing utility?
It's the same runtime.

Don't get me wrong. I regularly sing the praises of eix, and quite often whinge
that someone should just work with you properly, in #gentoo-portage, no doubt to
their annoyance. But I don't code python, nor am I about to start, and you don't
do IRC, so there's not much I can do about it.

But in general we filter most of emerge's messages, in case there's something
important like a news item, leftover config-updates, a profile upgrade, package
moves and so on. And any message emerge spits out as IMPORTANT. Those can come
up during sync as well.

> eix-sync alone normally uses this order (only relevant tasks listed):
> 
> 1. layman ...
> 2. emerge --sync [ hence, followed by postsync.d hooks ]
> 3. @-hooks from /etc/eix-sync.conf
> 4. eix-update
> 5. eix-diff

Well we do emerge --sync, then by default run: eix-sync '-0 -N'

That's changed once before, a few years ago, actually after discussion with you,
around the metadata sync times. But I'm happy to change the default flags again,
if you recommend something else. As is, it's always been a config setting, and it's
up to the user to explore the wider Gentoo landscape. In this case that's the massive
manpages for eix.

If you want us to run it in a different order, that's of course fine too. I don't
use overlays, I just like the tree diff from eix, and the speed of querying.
Note the user can override with postSync hooks as well. If it's layman --sync for
example, it gets run as the wrapped layman --sync command, after eix-sync. The idea
there is that a user who is using eix doesn't set that, and instead tells eix to do
it all, which is what we've been advising since 2007/8. But another user might.

(or ofc it can be a user-defined function.)

We don't shield the user from emerge: that's not update's purpose. It's designed to
make the routine decisions easier, that belong in a higher layer, closer to the user
and not to the package manager: ie scripted. An example of that is, we don't support
uninstall: in a few places we just tell the user to run emerge -Cq package (like
update -h/--help, and iirc in depclean or one of those maintenance tasks.)

And to give you all the info at the time you're making a decision. But we take the
position that dumbing-down Gentoo is a disservice to everyone: all you're doing is
postponing the inevitable, and the user who's done their own manual install, and knows
how and where to setup files, is much more likely to stay the distance, and be able to
recover when the idiot-box is being an idiot.

That's why coloured diffs of the relevant files are nice, since it reminds you where
stuff goes on, at the same time as you're confirming changes. Of course, if you want
to get complex, it'd probably take as long as trying to explain eix, given the amount
of additions that have been put in over the years, for binhosts, tinderboxes, chroots
etc.

> so if you use postsync.d to update a local overlay according to changes in
> the tree (or of a layman overlay) this update should be visible in eix.
> If you do not use eix, postsync.d should do as well...
> 
> If you want to avoid postsync.d (though I still do not understand why)

Again, that's because you're reacting to certain statements without considering
the whole. Likely because they're things that annoy you, with many of your users.
I know the feeling ;)

The simple fact is I raised postsync immediately, and was still musing as to how
we could use it. But as you've shown above, there's a lot of stuff that goes on
after the postsync (and overlay's have to be considered.)

That's why I've always recommend our users use eix to manage their overlays. We
wrap layman sync as well, but for end-users our advice has ALWAYS been: use eix.

I have no clue where Duncan's stuff comes in as yet, and it still sounds like it
needs reworking and QA once it's actually producing an overlay, as opposed to gobbing
all over the local mirror. If the process can run in postsync, that would be ideal.
As I already stated.

Seriously, I'm on your side. I've personally been using eix to display the tree, and
gladly, since the beginning.

So chill out ;)

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

[prev in list] [next in list] [prev in thread] [next in thread]