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