On Thu, Jun 26, 2003 at 04:21:15PM -0400, Elliot Peele wrote: > > What about the people that would rather have it without the (noreplace) > that would then have to rebuild the rpm to take it out? > I haven't seen any email of someone either wanting this, or explaining why this would be desirable in any way, I have given some reasons on why the opposite seems more reasonable, including the one at the end of this email, and some more people seem to agree on this. [ the following paragraph is on the /etc/yum.cron.conf file ] > > I don't think this is really the way to go, it just seems like a bad > idea, maybe its just because no one else does it. > Probably because it's a better idea to not overwrite the cronjob :) > > My other suggestion of splitting yum into two rpms would also fix the > > problem (but is overkill). If you want automatic updating you install > > yum-service, or not if you don't. There are two "semantically" > > different things packed onto the same rpm (1. the tools, 2. the > > update service). I don't think that's necessarily bad though... > > Again...you don't see other rpms do this. You do see this (splitting one "software" into several packages according to their "semantical use"). Some examples: sendmail, kernel, glibc, tetex, gtk, perl, XFree86, krb5, openssh....), however, as I have said before, I don't think this is the proper solution for this issue, and I think it's mostly overkill (inefficient) to do so. I just mentioned it as an extra possiblity. > In looking through some of the spec files for Red Hat packages that put > files in /etc/cron.daily it seems to vary. For me personally I would > rather it not be set as noreplace, but I modify the package already it > wouldn't be a big thing to just remove it. Other argument on why yum.cron should not be overwritten is this: It is already marked as a config file, so I don't have to convince you that it is in fact such. In general packages should not overwrite config files, unless a configfile format change happened on this version, and the previous one is invalid for sure. To do otherwise, means that with every upgrade the sysadmin will have to reconfigure the package (mv foo.rpmsave foo), this is annoying and error prone. So to emphasize: There are only two possibilities (kinds of users): - You modify yum.cron: then you either build your own package because the existing one is flawed. Or have to remember to replace yum.cron on every update. - You don't touch yum.cron: In which case you couldn't care less if it was or not overwritten by the upgrade. So why not go with what's best with the other guys (the ones that need to modify it). To me the solution is obvious. Carlos
