Hi Seth, don't worry, we won't hold it against you. These changes all look exciting. I'm curious about the hdlist hack/change. When is it that the hdlist files get put there? ie. if I am running yum in the %post section of a kickstart install, will it be able to access them? I assume that this change means that the headers will *never* need to be downloaded from the RH base repository - only from the updates & whatever other repos. Is that correct? Thanks, Jeff On Sun, 2004-02-22 at 23:37, seth vidal wrote: > Hi, > So, I said something, to someone, at some point, about not adding new > things to 2.0.X and just moving ahead. Well it looks like I won't be > able to hit the freeze for fedora core 2 for the new metadata-enabled > yum. It just isn't in the cards. So instead I decided to do a number of > hacks to 2.0.X that are landed or intended for HEAD. > > So here they are: > --exclude= - on the command line - let's you add global excludes, one > package name or package glob per --exclude= - you can specify it > multiple times. > > --download-only - yes - I know - at long last - it will just download > the packages then exit - it's up to you to go find them. This is also > available under [main] in the yum.conf file. > > bootloader=0|1 - lets you specify whether you want yum to muck with your > bootloader or not. A couple of caveats. As of right now grubby does most > of the heavy lifting for kernel updating - it's called from the kernel > packages %post on fedora core, red hat and yellowdog systems. If you do > not have a reasonably recent grubby then it doesn't support lilo > reconfiguration. If you are one of these people AND you're running lilo > do NOT set bootloader to 0. It won't hurt anything, but it won't add ANY > entries to your lilo.conf - not only not just making them the default. > > - ryan fixed the urlgrabber not properly escaping password/username > configurations > > - fixed a couple of problems where the lockfile error handling didn't > work on non-english systems. > > I also made one hack that should speed up a lot of people's initial > runs. If you have the hdlist and/or hdlist2 in (by default) /usr/share/ > comps/$basearch/ then yum will look in those for the headers it needs > when it first runs. If it can find them then it will write them out to > its header cache. This is being done as a temporary and fairly-icko hack > until the new metadata work is ready. The benefit is that for the first > run of yum this will have a big benefit to people on slow connections or > with goofy mirrors. > > You can set the path to the hdlist and hdlist2 files by setting: > hdlist =/some/path/to/the/hdlist > hdlist2 =/some/path/to/hdlist > in [main] > > if you'd like to disable this entirely just set: > usecomps=0 > > under [main] > > ok - so that's the gist of the changes: > Tarball: > http://linux.duke.edu/yum/download/2.0/daily/yum-20040223.tar.gz > > Source rpm: > http://linux.duke.edu/yum/download/2.0/daily/yum-2.0.5-20040223.src.rpm > > RPM - built on fedora core 2, test 1 (ish): > http://linux.duke.edu/yum/download/2.0/daily/yum-2.0.5-20040223.noarch. > rpm > > let me know what I broke, I'm sure it was a lot. > > -sv > > > > _______________________________________________ > Yum mailing list > Yum@xxxxxxxxxxxxxxxxxxxx > https://lists.dulug.duke.edu/mailman/listinfo/yum
