(Jul 25 2005 11:36) Andy Bakun wrote: > Well, swup is basing its decisions on the dependencies listed in the rpm > file(s), so if mysql requires perl-5.8.5-5tr or even perl-5.8.5, rather > than perl-5.8 or just perl, it's always going to update.
Wrong. It's always going to update anyway, since perl is new and the mysql package might benefit from that new perl. > Unless swup is trying to be "too smart" by just looking at the package > name and ignoring the version number and just adding the package name > to the update list -- and voila, there's a new version, so update it > too. I don't know exactly how swup works in this regard, but what > I've described seems overly complex. Your description is not just overly complex, it's also just wrong. :) 1. Perl is updated 2. mysql requires /usr/bin/perl 3. mysql is scheduled for update as swup wants to keep your system as up-to-date as possible. That's how simple it is. I'm considering rewriting this to: 1. Perl is updated 2. mysql requires /usr/bin/perl 3. swup tells the user that he should consider upgrading mysql as well. Would that suit your needs better? > Maybe, as far as mysql goes, support scripts should be moved into > another RPM, and that RPM can require perl. This will actually make it > much more obvious what is being updated in the large package system that > mysql is when there are multiple packages with interdependencies. I > think this would need to be thought out more. Splitting support scripts into sub packages is something to consider since it will make it more transparent to the user why a package is updated. However, it's a trade-off as well, since it makes it harder for the users that expect the support scripts to be present after installing the main package. > A more realistic scenario is the recent zlib bug that required an > update. I wanted to update the zlib shared libraries as soon as > possible (partly so I wouldn't forget/get into the habit of waiting to > apply important updates, and partly because I wanted to update the > minimal amount as outlined previously), but wait on updating mysql until > a maintenance window. Partitioned updates also decrease the required > size of the maintenance window (especially if a problem crops up). > > This is partly because I know that the zlib upgrade just adds new files, > whereas the mysql upgrade stops and restarts mysql, and has postinstall > scripts that create databases and warns about setting passwords and > whatnot, and overall is a much more "complex" package. (of course, I > realize that in order to actually get the benefit of the zlib fixes, the > services that use the zlib .so will have to be restarted anyway). As mentioned before, I have no problem understanding why you want to partition updates. > The other thing is that I can say to the other sysadmins "make sure > everything is updated on this machine EXCEPT mysql, we'll have the local > mysql expert handle/be around during the upgrade in case anything goes > wrong" (because I associate a "complex" package with increased > "delicacy", prone to problems). I suppose in that case I could put > mysql in the exclude list in swup.conf, but then the swup.conf needs to > be edited when you do want to actually have swup handle those packages > (and then reverted when you're done) -- increases the chances of things > going wrong because more files need to be touched. Wrong. when you want to include mysql, you run with '--ignore-filter'. Edit the file once, smile forever. > Also, adding something to the exclude list will have it be ignored in > my cron job that sends me email saying something needs to be updated. Sure about this? If I recall correctly, you will be notified that swup skips those packages if update candidates are available. > > > It might be that the behaviour you suggest with swup including as little > > as possible when run with arguments, and running with no arguments > > equals '.*', is the prefered behaviour. If we deside it is, then I can > > change how swup does this soon enough. If --local-first does not work > > the way I explained (remember that doing this was not the main reason > > for --local-fist anyway), I will have to modify it to do that, since > > having the option to do both is desired. > > I will try it the next time I'm applying updates. > > -- > Andy Bakun <[EMAIL PROTECTED]> > > _______________________________________________ > tsl-discuss mailing list > [email protected] > http://lists.trustix.org/mailman/listinfo/tsl-discuss > -- Christian H. Toldnes Trustix Developer _______________________________________________ tsl-discuss mailing list [email protected] http://lists.trustix.org/mailman/listinfo/tsl-discuss
