On Tue, 2008-10-14 at 16:48 +1300, Martin Langhoff wrote: > On Tue, Oct 14, 2008 at 4:24 PM, James Antill <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Fedora -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list