Re: Security Updates in Slackware64-14.2
Robby Workman via slackware <[email protected]> Sat, 11 Nov 2017 14:14:27 -0600
| Newsgroups | gmane.linux.slackware |
|---|---|
| Organization | Generally OCD |
| Message-ID | <[email protected]> |
On Fri, 10 Nov 2017 12:57:50 -0500 (EST) Sylvain Robitaille via slackware <[email protected]> wrote: > On Tue, 7 Nov 2017, Robby Workman wrote: > > > While it would be nice to have the installer take care of the > > post-release patches automatically if using http/ftp/localmirror > > as an installation source, after looking at the installer code, > > that is not an undertaking that I wish to inflict upon anyone, > > much less myself. :-) > > How would the installer handle, for example, multiple versions of the > same package in the slackware/${subset} directory? Well, the idea I had was to do one of the following: 1) if a different version of the package in ./slackware(64)/*/ is in ../patches/packages/, then install the one in ../patches/packages instead. This is the more difficult of the two options. 2) once the system is fully installed, add a prompt to upgrade any package present in ../patches/packages/ -- this would be like the prompts to e.g. use a custom console font > For example, if my tagfile for subset "n" has "bind: [ADD]" and rather > than having Slackware's update packages for bind in a "patches" > directory, I have them in "slackware/n", would the installer ... > > a) install every version found, thus overwriting most of the files > anyway, though leaving a bit of a mess in /var/log/packages, > and certainly leaving any files that might have been removed > from a newer version of the package; > > b) install only the highest numbered version of the package; > > c) complain that it doesn't know what version to install; > > d) barf, or perform some other unpredictable action? Yeah, that's basically the issue with option 1 above. The only sane option is not listed: install the one in ../patches/packages/ instead. > Oh, that reminds me of an additional option I'd love to see in > "setup": > > - use tagfiles, but prompt for new packages > > I know the tagfiles option is intended to permit unattended package > installation, but new releases of the OS always have new packages > (and sometimes remove or rename some), so it always seems like I > need to install at least one system manually in order to *create* the > tagfiles in the first place, and since I have tagfiles for multiple > system "types" ("router", "server", "desktop", "laptop"), I often find > myself not bothering with the tagfiles. It would be nice to be able > to use an existing set of tagfiles, but still handle new and/or > renamed packages, and it would be nice to be able to automatically > create a new set of tagfiles from the current contents > of /var/log/packages. Hrmmm... I guess that's yet another suggestion, > though frankly I might be able to script that one myself, if I just > took the time ... I don't think I like that idea. I do understand the problem though. I think the best option is to have a look at the CHANGES_AND_HINTS.TXT file on the mirror for the new release - I personally maintain that file, and among other things, it has a list of every package that was added or removed since the prior stable release. -RW -- slackware mailing list [email protected] https://mailman.lug.org.uk/mailman/listinfo/slackware