[Server-devel] XS 0.5 upgrade notes
jvonau at shaw.ca
Thu Nov 13 11:45:05 EST 2008
Martin Langhoff wrote:
> On Wed, Nov 12, 2008 at 12:10 PM, Jerry Vonau <jvonau at shaw.ca> 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:
>> 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
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
> 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
> Great to have you back on board!
Just had other stuff on the front burner.
More information about the Server-devel