Martin Langhoff wrote: > On Wed, Nov 12, 2008 at 12:10 PM, Jerry Vonau <[EMAIL PROTECTED]> wrote: >> Well, since /etc/yum.conf is provided by yum itself, there should of been a >> yum.conf.rpm(olpc?)new file created as not to overwrite our modified one. > > Ok - I've pushed out a new xs-config that should address the issue. > The problem is that the yum.conf file in xs-0.4 was tampered with from > a %post script. Nasty stuff, so the user 'hasn't changed it' but rpm > things it's changed. > > There's a sane and safe workaround -- but your peer review is more > than welcome -- in the new xs-config. Can you (or Douglas) confirm > that the old file we want to replace has a sha1 of > 2f12835cb11f100be169abcc8bff72525a25cff7 ? > > The patch is here: > http://dev.laptop.org/git?p=projects/xs-config;a=commitdiff;h=b81ed4df7a1a534fcf8c2249e739a03def3c75dd > >> Think the best way out of this is to have xs-release move/rename the current >> yum.conf file. > > Well, xs-release is doing the right thing, but the old xs-config made > a mess of it all. > > Hmmm. Perhaps the patch I've done should be actually be placed in > xs-release instead. > Your fix should work fine.
>> Since the topic of "yum upgrades" came up, is this support wanted? I'm >> thinking that this could be doable from the cdrom and/or across the net. > > Yes. I don't know if it's reasonable for a 0.4->0.5 upgrade as it's > rather large and full of nasty odd corner cases. In other words, it > may work but if it breaks I don't think it's worthwhile to fix it. > Going forward 0.5->0.6->0.7 will probably be all F9 based so yum > updates will be trivial. When we move to F10 or F11 we'll have to > evaluate whether it's within reach. The good news is that the Fedora > team seems to be interested in polishing the "in place" update > machinery (which I assume is yum), so I want to ride on that wave if > possible. > I tried a yum .4 -> .5, the change in the network scripts makes this rather unworkable, best to use anaconda here at least for .4 -> .5. Using yum updates after .5 should be a non-issue. >> To help make this installation easier to use, we may want to define a >> "group" in the comps.xml file. This would allow you to install the >> xs-release rpm, to activate the repos, then do a "yum groupinstall >> xs-school-server" then your off and running... > > Is that better than xs-pkgs? Well, for anaconda, not really. For yum, the listing of the xs-* file with mandatory for our group would install the listed files when you use "yum [groupinstall/groupupgrade] ourgroup ". It's more like shorthand for "yum install xs-config xs-pkgs xs-....." Also should offer the chance not to install some packages that we my not want installed by default. > My concern is that comps.xml is not > modular AFAIK -- there is just one, so we can patch it, but then we'll > want to merge with the upstream one. Yes, we can do it, but it seems > awkward. I'm not clear on how we publish it either - does it become > published as part of our repo? Yes, the changed comps.xml file becomes part of the repo when you use -g (to point to the edited comp file) with createrepo. > Do we have to convince Fedora to carry > our changes to comps.xml or users to download ours and point their yum > config to it? > Nether, the comps file would be merged with the stock one by yum. I'll need to review yum for anything that may of changed in respect to group handling when 2 comp files are present. > IOWs, I understand how a metapackage works much better :-) > >> I'll have some time to throw at this in a day or so, if there is any >> interest. > > Great to have you back on board! Just had other stuff on the front burner. Jerry _______________________________________________ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel