SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
My hat's off to Pat: thanks for providing the choice! Everything has been working smoothly here since switching to pure Alsa. I'll be fine with whatever patching (Patching?) solution will eventually be adopted for extra/.
Has updating in-place ever been considered for Slackware? i.e. instead of a patches/ directory updated packages replace older ones in the main-package tree?
OpenBSD follow that model with a release (which is a fixed point in time), stable (which gets overwritten with important/security updates) and current (development) tree.
Personally, it's a model I like and I could see it working for Slackware. It would also cater for this particular scenario.
Have we not had that since forever?
Release - What is on the official install media.
Stable - What is on the official mirrors. The patches/ directory largely tracks changes since release.
Current - The official development tree.
What is new here is the ability to use an alternative package set based on the choice of sound server.
Would you mind elaborating on what are the benefits to this method and the drawback of using a patches/ directory? Seems more or less the same from my perspective, but I've never used openbsd so I could be missing some details?
Firstly, there's the fact that patches/ grows over time and obsoletes packages in the main tree, but those packages still take up space and are never removed. So that's one advantage that updating in place has. Another is that utilities like slackpkg don't need to differentiate between stable and current branches and can treat them the same (there's no patches/ to handle).
But the main point was raised in this thread. We now have two sets of alsa related packages. Where does Pat put updates? patches/ is for the main tree, where would updates for the extras go?
There's plenty of ways this could be handled of course. I was merely asking if what I outlined had ever been considered.
Don't get too hung up on the OpenBSD reference, it really doesn't matter. it's just one example. I'm sure other linux distros may do similar.
But the main point was raised in this thread. We now have two sets of alsa related packages. Where does Pat put updates? patches/ is for the main tree, where would updates for the extras go?
There's plenty of ways this could be handled of course. I was merely asking if what I outlined had ever been considered.
It's what was done for years before there was a patches directory. While I'll probably update the /extra things in place, I can't think of any reason other than saving some storage space to move back to an in-place upgrade model for packages in the main tree. The primary drawback is that if I really mess up an upgrade (it happens, but hopefully not too often) then there's no package to fall back on unless you can find an out-of-date mirror. It's also easier to spot what has been upgraded when it's all in the /patches directory.
The primary drawback is that if I really mess up an upgrade (it happens, but hopefully not too often) then there's no package to fall back on unless you can find an out-of-date mirror.
I never got anything from you wrecking my system for the 14 years I've been using Slackware. Can't at worst the fallback (holed) packages always be found in the ISOs? What sounds good with the Gazl's proposal is you know once for all where you will find the update of any package, and you automatically get a release up-to-date when installing it from the FTPs (esp. the kernels, otherwise requiring a reboot).
Since you mention it, in the model I was outlining, in addition to the "15.0-stable" tree that would be updated in-place you'd also have a static 15.0-release tree (fixed on release day). So the original packages would still be available somewhere. Obviously this takes up double the space on the server on release day, but you get some of that back from not having an ever increasing patches/ directory.
How big is 14.2's patches/ right now? (I'm running -current so I don't have it available to 'du')
And yes, being able to get an up to date install image from the 15.0-stable tree was not lost on me.
Pat's comment about the visibility offered by a patches/ directory is valid however, but one could argue that the changelog is sufficient visibility
If it were my distro, I'd do it this way, but it's not, and if Pat is content with the current approach then I'm not about to argue with him. It has worked so far.
Since you mention it, in the model I was outlining, in addition to the "15.0-stable" tree that would be updated in-place you'd also have a static 15.0-release tree (fixed on release day). So the original packages would still be available somewhere. Obviously this takes up double the space on the server on release day, but you get some of that back from not having an ever increasing patches/ directory.
The patch directory for Slackware only has the latest versions of whatever has been patched, so it would seem to save quite a bit of space compared with having redundant copies of all the stuff that hasn't been patched from 'release' in 'stable'.
Last edited by drgibbon; 05-28-2018 at 05:59 AM.
Reason: delete some stuff
The patch directory for Slackware only has the latest versions of whatever has been patched, so it would seem to save quite a bit of space compared with having redundant copies of all the stuff that hasn't been patched from 'release' in 'stable'.
It kind of depends on your viewpoint.
On the central server and mirrors yes, but when you factor in all the bandwidth used by people having to download duplicate packages to apply patches after an install you start to see a different picture.
Which is most efficient from a pure cost perspective isn't going to be quite so black and white.
I suppose one could also initially hardlink the files between 15.0-release and 15.0-stable if server diskspace really was such an issue.
Well bandwidth is a different issue, but yeah it would be nice to install and not have to patch, although the ISOs would have to be constantly updated to achieve that.
How big is 14.2's patches/ right now? (I'm running -current so I don't have it available to 'du')
Here you go GazL.
This is for my Slackware64 14.2 system, with an up-to-date local mirror thru Fri May 25 23:29:36 UTC 2018
Code:
# for d in slackware-14.2-32 slackware-14.2-64 ; do du -smD $d ; du -smD $d/patches ; done
8379 slackware-14.2
1831 slackware-14.2/patches
8293 slackware64-14.2
1784 slackware64-14.2/patches
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.