Thanks a lot for your notes. *Extremely* useful. A few comments below, On Tue, Oct 14, 2008 at 5:39 PM, James Antill <[EMAIL PROTECTED]> 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 -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- Fedora-buildsys-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
