On Tue, 2005-07-26 at 10:55 +0200, Christian Haugan Toldnes wrote: > 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?
I think this would make sense in the packages-have-been-specified-on-the-command-line case, yes. > 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. This would effect only "new" trustix users. Hopefully, new users don't remain new users for long, once they learn about something. Although there is significant disadvantage in terms of learning curves to packaging things different than how either the author or other distributions do it (which I argued against two years ago, heh, also in relation to mysql). Do we really feel that non-critical support scripts should have their dependencies satisfied? For example: $ file `rpm -ql mysql` | grep perl /usr/bin/mysql_convert_table_format: perl script text executable /usr/bin/mysql_explain_log: perl script text executable /usr/bin/mysql_fix_extensions: perl script text executable /usr/bin/mysql_setpermission: perl script text executable /usr/bin/mysql_zap: perl script text executable /usr/bin/mysqld_multi: perl script text executable /usr/bin/mysqlhotcopy: perl script text executable This is a bad example, if these are critical or not could be debated (although I don't think *I*'ve ever used a single of them). convert_table_format is only used on an upgrades, fix_extensions is only for migrating from Windows (and the comment at the top is telling :) ), explain_log and set_permissions needs DBI too (ouch!), set_permission is for people who don't want to read the mysql manual, and mysql_zap is better known as /usr/bin/killall. Heh, I'm not sure which way I just argued for these being critical or not. The actual USEFUL scripts (in my experience), like fix_privilege_tables, create_system_tables, mysqlbug, are written in Bourne shell. It'll be difficult to divide anything up that will make everyone happy, even if it does make sense, I'm not sure I'm willing to part of that particular can of worms. I want to suggest that the rpm's deps be changed to be more relaxed, but this makes package metadata incomplete (if a perl script is included, the package obviously requires perl to be fully functional) in order to make installation/upgrade and related tools easier to use. As such, I think changing the installation/upgrade tool, swup, is the best way to go (which you've already been advocating doing, I'm just explaining my reasons for coming to that conclusion). > Wrong. when you want to include mysql, you run with '--ignore-filter'. > Edit the file once, smile forever. Excellent. > > 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. Mmmh... it prints a message that it's skipping it if it does need to be updated, but it's in a different format than the update messages and is worded to be more diagnostic than as part of the requested (--poll-only) results. As a side note, I generally have a problem with swup's output anyway. The use of \r to give live, incremental updates doesn't lend itself well to browsing in log files. There also seems to be some weird "clear the line" action that overwrites 80 characters with spaces, but my window is often wider than that, so there ends up being a lot crap/half-lines in the middel of the screen. This was more of an issue with older versions, I have not been as annoyed with it when using swup recently. -- Andy Bakun <[EMAIL PROTECTED]> _______________________________________________ tsl-discuss mailing list [email protected] http://lists.trustix.org/mailman/listinfo/tsl-discuss
