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

[James Antill]

On Tue, 2008-10-14 at 16:48 +1300, Martin Langhoff wrote:
> On Tue, Oct 14, 2008 at 4:24 PM, James Antill <james at fedoraproject.org> wrote:
> >  But if you are going to ship a repo to end users which requires/uses
> > the yum-priority plugin (or excludes, or whatever),
> 
> 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.

> > then the simple
> > advise I would give you is: _don't_.
> 
> Can you tell me a bit more about why? (I definitely respect your
> technical advise, I'm trying to get more depth of info / experience on
> this...)

 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.

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.

> 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.
 Of course how much the cross repo. deps. problem hits you depends a lot
on the package, ejabberd doesn't look like it requires anything that
might be upgraded in a bad way ... and has no deps. on itself. So there
is a certain amount of "try it, it'll probably work fine".

> I am already down that path with Moodle ("moodle-xs"), which I plan to
> maintain as a long-term heavily customised package.
> 
> >  Instead clone the Fedora repo. removing the packages you want to
> > "override"
> 
> Quite a bit of work if I also want to give them access to sec updates
> in a timely fashion :-) and my "conflict" with Fedora packages is
> tiny.

 Yeh, I completely agree this is harder to do than it should be right
now ... as an end game it'd be nice if there was a way so you could just
publish a repo. which was "Fedora - <set of packages>" but all/most of
the package hosting was done via. the Fedora mirrors etc.

> > ... or even better get your changes into Fedora.
> 
> In some cases Fedora won't want them as they are strictly local
> customisations -- such is the case of ejabberd and moodle. In others
> Fedorans are looking into  integrating changes in their own timeframes
> (and I have my own release schedules to work for :-/ ).

 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...

> 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 :).

-- 
James Antill <james at fedoraproject.org>
Fedora