Thanks a lot for your notes. *Extremely* useful. A few comments below,
On Tue, Oct 14, 2008 at 5:39 PM, James Antill <james(a)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(a)gmail.com
martin(a)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