Re: [Server-devel] Tying yum to a package stream?
On Tue, 2008-10-14 at 18:49 +1300, Martin Langhoff wrote: On Tue, Oct 14, 2008 at 6:16 PM, Mike McLean [EMAIL PROTECTED] wrote: If you go this route, I think what you want is obsoletes. Obsoletes says this packages replaces this one. Conflicts says this package cannot be installed at the same time as this other one. Does 'obsoletes' also mean this package cannot be installed at the same time as this other one.? Because things *will* go wrong if someone installs moodle and moodle-xs :-/ You can obsolete and conflict Obsoletes: pkgname=ver.rel Conflicts: pkgname=ver.rel -sv -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [Server-devel] Tying yum to a package stream?
On Tue, 2008-10-14 at 18:49 +1300, Martin Langhoff wrote: It makes sense to freeze our repo and selectively update it with reviewedtested updates from fedora... if you have the focus on stability and the manpower to do it. Neither is true right now for me. Adding another time gap for release of updates is also problematic for any security updates which could already be time sensitive. Jeremy -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [Server-devel] Tying yum to a package stream?
On Wed, Oct 15, 2008 at 12:52 AM, seth vidal [EMAIL PROTECTED] wrote: You can obsolete and conflict Obsoletes: pkgname=ver.rel Conflicts: pkgname=ver.rel Great -- thanks! I'll do exactly this. m -- [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 Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [Server-devel] Tying yum to a package stream?
On Tue, Oct 14, 2008 at 3:27 PM, seth vidal [EMAIL PROTECTED] wrote: you can use yum's priorities plugin to achieve similar results. It's a bit simpler than apt but I can sure work with this. Thanks! Just as in the apt-world configuring priorities/pinning for longterm/widespread use is a frelling nightmare. :-) -- well stated. If people mess with the repo configs we provide, install random rpms or play their Heavy Metal Rock records backwards, they void their warranty. cheers, m -- [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 Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [Server-devel] Tying yum to a package stream?
On Tue, 2008-10-14 at 15:57 +1300, Martin Langhoff wrote: On Tue, Oct 14, 2008 at 3:27 PM, seth vidal [EMAIL PROTECTED] wrote: you can use yum's priorities plugin to achieve similar results. It's a bit simpler than apt but I can sure work with this. Thanks! Just as in the apt-world configuring priorities/pinning for longterm/widespread use is a frelling nightmare. :-) -- well stated. If people mess with the repo configs we provide, install random rpms or play their Heavy Metal Rock records backwards, they void their warranty. To expand on what Seth is saying, if you are doing this on your local developer workstation etc. ... feel free to do whatever you want to override the normal behaviour from the repos. (that's what the features are there for). But if you are going to ship a repo to end users which requires/uses the yum-priority plugin (or excludes, or whatever), then the simple advise I would give you is: _don't_. Instead clone the Fedora repo. removing the packages you want to override, or even better get your changes into Fedora. -- James Antill [EMAIL PROTECTED] Fedora -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [Server-devel] Tying yum to a package stream?
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. 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...) 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. 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. ... 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 :-/ ). It's a classic upstream/downstream game... cheers, m -- [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 Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [Server-devel] Tying yum to a package stream?
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
Re: [Server-devel] Tying yum to a package stream?
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 Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [Server-devel] Tying yum to a package stream?
Martin Langhoff wrote: 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. If you go this route, I think what you want is obsoletes. Obsoletes says this packages replaces this one. Conflicts says this package cannot be installed at the same time as this other one. One mechanism gives the tools instruction on how to handle things, the other is more of an assertion that mostly just causes the end user pain when it comes up. Building conflicts into your repositories is generally not very friendly. Sometimes it may make sense, but I'm not sure it makes sense here. 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. I think you could come up with a reasonably fast sync script if you wanted to go this way. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [Server-devel] Tying yum to a package stream?
On Tue, Oct 14, 2008 at 6:16 PM, Mike McLean [EMAIL PROTECTED] wrote: If you go this route, I think what you want is obsoletes. Obsoletes says this packages replaces this one. Conflicts says this package cannot be installed at the same time as this other one. Does 'obsoletes' also mean this package cannot be installed at the same time as this other one.? Because things *will* go wrong if someone installs moodle and moodle-xs :-/ 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. I think you could come up with a reasonably fast sync script if you wanted to go this way. Sure - rsync to da rescue! :-) - but then there is no review and testing, and we're back to the same situation as with pointing users directly to the Fedora repos. Field installs may break if an update comes through untested/unreviewed. It makes sense to freeze our repo and selectively update it with reviewedtested updates from fedora... if you have the focus on stability and the manpower to do it. Neither is true right now for me. cheers, m -- [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 Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
