[Server-devel] Tying yum to a package "stream"?

[Martin Langhoff]

Thanks a lot for your notes. *Extremely* useful. A few comments below,

On Tue, Oct 14, 2008 at 5:39 PM, James Antill <james at fedoraproject.org> wrote:
> On Tue, 2008-10-14 at 16:48 +1300, Martin Langhoff wrote:
>> I am shipping a heavily "preconfigured" spin, the OLPC School Server.
>> It points to the standard F9 repos, plus OLPCXS repos. So far we
>> override... 1 package: ejabberd.
>
>  Ok, that's kind of the worst case atm. ... I had assumed you'd be doing
> this to a lot more.

Yes - it is the worst case, and I don't expect to see this grow significantly.

>  There are two basic problems:
>
> 1. It's a lot less efficient to push the depsolving/repoclosure down to
> each client, instead of solving it once on the server. So from that
> point of view yum-priorities/etc. are _always_ going to give a worse
> experience, even if we have all the data, make the depsolver a full SAT
> solver while keeping it fast.

I did notice yum got a ton slower during the build once I added priorities.

> 2. Fedora doesn't provide all of the data to make the above possible
> anyway, so for instance F-9 might have foo-1.0-1 and then updates for
> F-9 might release foo-1.0-2, foo-1.1-1, foo-1.2-1 ... by that point
> _only_ foo-1.0-1 and foo-1.2-1 will be available (one pkg/version from
> each repo.).
>  This means that if your repo. has bar-xo-1.0 requires "= foo-1.1" ...
> all the old xo repos. now become broken you have to rush out a fixed
> bar-xo and wait. You would still have "problems" if you did everything
> server side, but you'd actually be able to run repoclose/etc. and see
> the problem before it hit the clients ... and just not update your
> cloned repo. until you fixed it, with yum-priorities the first you'll
> see it is when all the clients don't work anymore.

Good point -- though with every custom package in the XS build I have
ample room to shoot myself in the foot with tight dependencies... with
or without priorities. True, getting fancy with tight interdeps
hjandled "transparently" via yum-priorities leads me in the wrong
direction...

>> As it's a single package and this could expand to a couple more
>> packages but no more, one alternative is to take that single package
>> and rename it ejabberd-xs and set it to provide:ejabberd,
>> conflicts:ejabberd.
>
>  This is a lot better, in that it totally solves #1 above. #2 still
> applies (cross repo. deps. are the suck) although due to the rename
> it'll be to a lesser extent than trying to override packages with higher
> NEVRA.

Right - so we'll move to that model then and drop priorities. the
packages will look a tad funny, but it's ok.

We currently don't have any tight or tricky dependency, though our
repo is of course referring to stuff in fedora and
fedora-updates-newkey. Depending on php, httpd and python is not
something I stress about -- if fedora breaks any of them
significantly, I won't be alone in my anger... :-)

>  Is there any way you could make the changes be basically bolt on
> config. changes? so you have a ejabberd-config-xo or whatever? I'm
> guessing you already looked at that, but I thought I'd ask...

Where we can, we do -- currently in a xs-config package that rolls
together lots of config overrides -- we'll break that down in due
course.

For ejabberd we have custom patches...

>> It's a classic upstream/downstream game...
>
>  Yeh, but think of it like Fedora vs. our upstream ... we copy all
> the .tar.gz files locally, because we need to be isolated from changes
> on their side. Ideally you'd do something similar to be isolated from
> changes on our side, not being able to do that starts you on the road to
> a bad place ... and yum-priorities is at the heart of the bad place :).

There are two ways to look at that. You keep complete control over the
deliverable, which is definitely saner but requires a ton more
development resources.

In the case of the XS, we are still in heavy develoment mode (though I
do cut releases, they are not a finished product). A lot is in motion
and with a tiny team. Just keeping abreast of "what fedora updates to
accept" in any useful way would swamp us.

So at this stage I can't hope to keep such complete control :-/ once
things stabilise at our end, I will review my options.

thanks again!


martin
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff