My intent in asking this question here rather than just logging a feature request with the yum developers was primarily to foster some discussion among users on why this was/wasn't needed or a good idea. I think that happened, and I got some good ideas that can be pooled together to make a more representative, useful 'official' feature request. I've put a few further comments inline below... > > > How does this differ from -c [config file] > > > > > > yum -c /etc/yum-updates-released update > > > yum -c /etc/yum-watch-list list updates > > > yum -c /etc/yum-watch-list update foo > > > > > > To me it seems that multiple config files works just fine. > > > If I wanted to I could script up a wrapper (my-yum) that > > > did the same thing you are asking (use -c under the hood). > > > ... I agree that this would meet match most of the functionality I'm envisioning, but as someone else had mentioned, duplicating information is never a good idea. What happens if you've got a few different config files on that reference a repository who changes their URL? I think that adding an "include" directive would fix this quite nicely. > I guess one could have a wrapper that has a list of repositories and > presents the list for selection. It then cats them into > a temp config file and then launches "yum -c /tmp/yum-config$$". For an interactive mode, yes, this would work. But for an unattended, automatic update, this wouldn't be feasible. > Me, I have multiple /etc/yum-conf* files and with comments I can > inspect them "less /etc/yum-con* " and then use the one > I want... "yum -c". This is great for a single system, and is essentially what I do for mine, except that I use a single file and comment out the ones I prefer to ignore this time. However, on a wider-scale deployment, I'd really hope to use a more 'built-in' functionality. > Perhaps "yum -c configA -c configB" that acts as if configA and > configB were concatenated together. But even that does not work for > me ... I have different exclude=, exactarch=, retries=, pkgpolicy=, > failovermethod and other config flags that are different. Without knowing the exact settings you're using, I can't be certain, but I think that an "include"-type directive would be very useful here. And keep in mind that just because a feature set won't work for your particular setup doesn't mean that it's not a useful feature for one/some/many other(s). :) Thanks for the input so far - I'm planning to pull that info together for a feature request soon. -- Philip J. Hagen Red Hat Certified Engineer http://identityvector.com/~phil/ (PGP Key, software, etc) PGP key also at http://www.keyserver.net
