[gentoo-desktop] Re: kde-lean

[Steven J. Long]

Duncan wrote:
> Something that's been bothering me a bit.  So far, this "framework" is
> pretty much just a function in my sync script that applies my patches
> after a pull.  It's pretty simple, not even that much code or time,
> actually.  So it'll need adapted for a wider audience, but I /do/ hope to
> get at least the initial function posted to the forum before this
> "weekend" is over.

That's fine. Really it shouldn't be more than applying:
 /etc/portage/patches.ebuild/cat/pkg[-ver[-rN]].patch to the ebuild, and ensuring
that any extra patches are in /files for the overlay, which afaic is the
maintainer's job, but I'm happy for us to automate any part that's useful.

> Don't worry, the patches themselves are still manually created by /
> someone/, they're simply applied immediately after the sync (before a
> cache regen since they affect deps), and if they no longer apply for
> whatever reason, it's not fatal, so the result will simply be that ebuild
> returns to upstream gentoo/kde default and wants to pull in the semantic-
> desktop junk again, until someone comes up with an updated patch.

Yeah, though I don't want anything reverting to default like that, so we need the
package.mask of synonymous ::gentoo packages.
 
> > I just mean the overall design is one of patching as one process,
> > and use as a later, independent phase that does not have any awareness
> > of the fact that the ebuild has been patched (apart from the metadata
> > tag for QA.)
>
> You'll be happy to know that's the way it works. =:^)  I hadn't even
> consciously considered the other way until you mentioned it, I think
> because I too was so horrified by the possibility, that I rejected it out
> of hand and considered the separate phases the only realistic approach
> from the get-go.

Good. You should know, I feel the same way about the idea of patching the local
portage mirror. I'm not happy with use of local/named overlay as an "option":
afaic it should be the only behaviour. If you must keep the option to patch ebuilds
in-situ, fine. Just not as default: opt-in to that instead.

> > Okey-dokey: I'll mail you off-list in the next day or two
> Cool. =:^)

Did you get my email? Worried I might have hit a spam-filter.

> But my system parallels emerge much more closely, being in effect little
> more than a bunch of emerge aliases, most of them starting ea (emerge --
> ask) or ep (--pretend), with various other letter combinations added that
> parallel the similar emerge options (eaw= emerge --ask @world... with
> --update --deep --newuse --oneshot implied, etc).
>
> The parallels make it very easy to transfer emerge option knowledge to my
> system, and the reverse as well.

I think you're a bit misinformed there: update _mirrors_ emerge options (or it's
a bug.) The -h for short options (--help for long ones) starts:
Usage: update <options> [target list]
 Options: -eapqvurnUDNoO[bB][gG][kK]iEmsSfFlRACMhtxXWYzc
           -eapunDNo[bB][kK][gG] : same as emerge

The only difference that would matter in usage, is that you have to use -i to
install something to world.

So update -uD --changed-use system # for example does the same thing emerge
would do. It just does the --pretend --verbose bit for you and waits for you
to review the output, as we're recommended to do, and gives you a dialog to edit
the list, and set package/global USE flags (or more commonly, read wtf they are;)
before continuing.
[You could use -U instead of --changed-use. That may be coming in portage, if zac
feels like it; he said it's free, anyhow.]

If you don't tell it to do something else, it assumes you want to:
  emerge -uD --changed-use world --with-bdeps y
followed by glsa-check, depclean and revdep-rebuild. At the end it runs
dispatch-conf (or etc-proposals et al) if needed (and not automated.)

So update -s syncs the tree, runs eix-sync which handles overlays and displays
the tree-differences, and then does the above.
[If that's wrong wrt eix and overlays, especially given that q's postsync runs
before eix, then someone please tell me what to do instead.]

That's the short version. ;)

So I'd argue update inculcates just as much transferable knowledge: for most things
you use it as you would emerge, with the exact same flags, but s/emerge/update to
let it provide "porcelain" around the command-line interface to portage.
Additionally any changes to config files are presented as coloured-diffs you have to
confirm, so while it saves time, it also reminds one where things happen.

With changelogs for downgrades (i think it is), while I knew it's the right thing to
do, I never bothered to check them. Having knowledge of how to do something, doesn't
mean one wants to type it in every time: it breaks the flow.
That's what scripts are for.

> > All in all, I'd say people who think bash is slow are using it wrong.
> > Shell-scripts are slow, because people call externals when they don't
> > know better, typically on a crap OS that can't handle fork very easily,
> > whereas it's trival on Unix.
>
> I think a large part of it is that people forget just how slow the
> machines were that shell had to still be practical on back in the day.
> As a consequence, it's pretty impressive on today's machines, even if
> it's not as efficient as tuned native code.

Indeed: Unix sh has been doing the job of javascript in polkit since the days of
8-bit CPUs with 16-bit address-spaces. And an awful lot more too.
But if you fork lots of externals when you don't need to, your shell-script will be
slow, so people who script all the time, simply don't.

wrt "tuned native code" most of the people who look down on sh have no idea what
that means. They typically come out of Uni knowing Java, and deign to learn python,
so as to share their "talent" with the rest of us. They tend to look down on C too,
or "view it as a necessary evil" given that every sane OS is written in it.

Functional programmers tend to be a bit more open, since the idea of macro expansion
is not a dirty concept to them, and Guy Steele is hardly a slouch when it comes to C.
The trendy haskell boys (we love you #gentoo-haskell ;) need gcc to compile their
code.

> Meanwhile, it's my "weekend" now (three day but with a meeting tomorrow),
> so I've a couple days to spend on this and other personal projects.  My
> goal is to be posting in the forum by the end of it, preferably with the
> first code posted.  We'll see.
..
> >> Short term, is it worth it to post the 4.10.80+ patches
> > Do please post them to the forum thread, in a [code]block[/code]
> > Or at a reasonably light pastebin with a [url=http://..]link text[/url]
>
> Thanks.  Hopefully in the next couple days...

Uh-huh ;-) If you're obsessing over ebuild-patch before you release anything,
a) don't: nothing crafted by human hands is ever perfect, and
b) can you at least post the patches to KDE ebuilds you've built and run?
They don't need to be the exact versions we'll use, though we do need the original
as well as the patch(ed version), if it's not been in gentoo-x86 cvs. commit-ids
are fine for originals from gentoo git.

Alternatively, just push your current KDE-4.11 ebuilds to the overlay (kde-lean repo).

> FWIW, I generally update about twice a week on my main machine.  I have
> something, somewhere, configured to warn me if I go more than a week
> between syncs, but AFAIK I've only actually seen that warning once, and
> can't even remember where it's configured.  Three months... I'd have to
> be in the hospital or something for most of that time.

Well it's due to specific circumstances: my system is in a state where it needs a
deep toolchain upgrade, which is something I've wanted since we started update.
So I'm pausing til it's done, which gives me an incentive to get it done. (Yes I
know about sets. ;) Normally I update 2 or 3 times a week.

We did the same when the expat upgrade came in: it took about 6 months to get ABI
upgrades working in chroot well enough that we could upgrade live machines in
confidence. Still, multi-binhost support and the installer came out of that, as
well as the /etc/warning capability. There was no way we were going to rebuild the
whole chroot every time: it was only about testing what it would do with a specific
package set installed.

It really is quite spooky watching emerge install from stage3 with binpkgs: it feels
almost wrong for it to sail through it as quickly as an rpm-based distro. I saw that
happen countless times, so I know Gentoo and portage rock for that usage.

Reminds me, we'll bring the installer up to date after --toolchain is done, so we
can finally release it: last time we worked on it, lspci -k was just coming into
unstable, then we didn't have enough time for it. But I need to reinstall a laptop,
and we're going to try to get it installing a raspberry-pi. (need a challenge;)

> > There's some nice stuff in kate for 4.11 I want to try though.
> With 4.10 I began running the 4.x.49.9999 live-branch builds from the
> gentoo/kde overlay, and now that they're available (and patched) for 4.11
> branch too, I'm running that.

Ah these mythical patches, I keep hearing about.. ;p

> What I'm /really/ waiting for is wayland, tho.

Heh it's quite a good contrast in use-cases: I'm incredibly conservative about
trying out new things when it comes to my desktop; I like it boring and reliable,
same as everything else I can't function without. (That's why I didn't go near
KDE-4 til 4.4; usually it's been x.2.) So if you're pushing to try the interesting
new technology, that's good as it means we're not going to be left behind.

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