Didier and me, we do not talk about slackware-current but the stable releases, e.g. Slackware 14.2

In other hand, is about the production ready releases, not about the development tree.

To build updated stable ISO download release ISO, mount it and copy content to other directory, download patches/packages/ from any mirror, replace packages, signatures and txt in series directories, recreate checksums, build new ISO.
Done. Not rocket science.

Hugh..:( Why, it is simple enough to install, then set the mirrors and slackpkg update, install-new, slackpkg upagrade-all, slackpkg clean-system. Now you are updated. The only purpose of a Service Pack, would be extra work for Patrick to constantly create new ISO's and ship them by a service provider, which has proven not-reliable to give PV any revenue for his work. Naw just leave the process as it is, it works and it is simply. KISS
Cheers, BrianA_MN

You assuming that you are able to manage to install the original Slackware version in your computer. Now imagine the combination: rookie + NVMe drive + Slackware 14.2

And yes, I am aware about this bit of extra work, but also I suppose there will be also the possibility of extra moneys gained. ;)

The fact that the shop used currently by our BDFL proved to not be so reliable is entirely another story.

I guess he can find a more reliable one, if he wants to sell DVDs...

My proposal in post #1947 is targeted as new users, not users wanting to update. And I assume that the same is true for post #1949 from Darth Vader (maybe the name Service Pack he used can be misleading, or I didn't well understand his proposal?). Also, providing a new ISO does not imply providing physical media.

Anyway Pat will decide what to do.

My bad. :(

Probably I smoked too much SLED (SuSE Linux Enterprise Desktop) but this idea of Service Pack is shameless borrowed from what SuSE do for its Enterprise solutions. E.g. we have SLED 12 SP1

They do those service packs since long time. And I seen them being sold pretty well... ;)

Of course, I do NOT ask also about a Slackware Linux Enterprise Desktop.

Yes, my idea was targeted mainly to the new installs, with an option to upgrade an existing installation. Which is possible in this context.

I would like to note that on some places on World, buying a DVD or torrenting a DVD ISO may represent a pretty good alternative to downloading packages from mirrors.

Please, do not forget about #1940 post. More information here.

For building xauth-1.0.10 with this patch (look at attached file xauth.git-bc78aa61cfbddaa27dee275f639ba40de6981b17.patch.txt - remove .txt) needs these dependencies:

• kbproto-1.0.7
• xextproto-7.3.0
• xproto-7.0.31

You can download them from these sources:
and for all
+ in the source of xauth-1.0.10 directory
Thanks!

proto headers are now all-in-one packages named "xorg-proto".

Yes exactly. I believe the NVMe drive is not supported by standard Slackware. What you are discussing is someone with a non-standard installation setup. Still once the install is done, the Service Pack update isn't necessary, since PV already includes the steps for updating the standard packages. If unique packages are needed due to some special hardware or configuration then that is not a process a Linux newbie should be pursuing. If your Service Pack is for unique hardware then it isn't "standard Slackware". It is instead a scenario to be covered by the wonderful helpful guru's, like yourself, here on LQ.
Cheers, BrianA_MN

@bamunds: NVMe is not supported (yet) by the installer of Slackware 14.2, but it is by the installer for current.

Chances are that a Slackware newcomer failing to install Slackware 14.2 on an NVMe drive will just think: "Slackware can't be installed on my machine, so let's try another distribution". Is that what we want? Providing an ISO with a modified installer would avoid that.

I know that a seasoned Slackware user will find ways to get the system installed reading this thread for instance, or using the installer for Slackware-current, but that's not that easy for someone new to Slackware.

So, let's say that NVMe is finally supported by the next "stable" release of Slackware. Again, if it is included in the standard release, then the installation still occurs as normal or per the Slackware included README files. Then it is simply a matter of still completing the standard updates to get the latest security and program updates.

Or, let's say the rookie picks the latest "current" release of Slackware. Then NVMe is supported as part of the installation. Again the updates are easily updated by the standard process suggested previously.

Also, there are always unpredictable interval security updates, which are received by Slackware users using the standard update process. Why would we suggest that someone wait for a Service Pack to get those updates?

In the end the idea of a Service Pack, regardless of how often, simply seems redundant and contrary to the Slackware way.
The only value in a "stable" Service Pack would be the concept of having the latest updated programs replace the original release on a ISO/DVD image. I think that means an additional point release system to keep track of which updates are included on the DVD, similar to what AlienBob does now with SlackLive releases. Oh, BTW, those are great LIVE CD's but still are not rookie installs. Cheers, BrianA_MN

I for one, I would not call the NVMe drives as "unique hardware" because NVMe stands for SSDs with a PCI-express x4 interface.

I do not know how is in America, but in Romania they are today pretty common drives, practically any decent laptop to buy today has a NVMe drive, excluding the really cheap ones, which sports, guess what? 16-32GB eMMC drives soldered on board. Also them not supported by Slackware 14.2

So, basically, if a Romanian buy a laptop today and he's a beginner on Linux, will not be able to install Slackware 14.2 on his laptop.

In other hand, those NVMe devices are bloody fast even compared with a standard SATA SDD which go up to 500MB/s. And at a similar price. For example this one: https://www.amazon.com/Samsung-960-E...dp/B01LYFKX41/

That 3200 MB/s for reading and 1900 MB/s for writing made it a pretty performant alternative to the "standard" SSD with SATA interface, which go (like I said) up to 500MB/s.

And the Romanians discovered quickly those adapters: https://www.amazon.com/dp/B01N78XZCH which permit to mount a NVMe drive on a desktop box, within the PCIe x16 usual for the video card or in a secondary x8 if it exists. And how for many the on-board graphics card is more than enough for their web-browsing habits and for movies watching, the new trend in my country is to replace the hard drives with those NVMe ones.

Then, contrary of thinking as "unique hardware" I would consider the NVMe and eMMC drives as being pretty common storage devices. At least in Romania - and certainly the same is in entire Europe Union.

I do not think that -current is for rookies. ;)

For example, for someone living in North Korea, and having the computer connected on their National Intranet (aka Kwangmyong) the single way to get updates for his Slackware could be some cousin from South Korea to send them on a DVD or a memory stick. A very risky business thought. If he's found by authorities, he may risk 10 years of forced labor. For contraband. So, better to not happen often.

WOW! There's a Slackware Way even for updated releases? :D

Please tell me more about that Slackware Way about updated releases. Even after using Slackware on the last 20 years, I have still to learn. ;)

Yup. It is about lightly updated releases.

I do not think that there's a rule that Patrick should update/replace everything for doing a release.

Let's say that the service packs will be small releases, done often, while the the main releases will be the major ones.

So, more products in the Patrick's Shop, more sales, then his bank account will be more happy and there will be more happy users. ;)

I think the thing to think about is that this would not just be incorporating all the patches/ directory into the main tree. It would be used to add minor improvements like hardware support and/or a more modern kernel to 14.2. There would be a handful of packages that would be newer than the standard stable patches.

The biggest issues with such spaced out releases is hardware support. Pat, rightly so, doesn't want to upgrade to a new kernel series on the stable release, and he has no way to modify the installer without replacing the 14.2 ISO. If he were to have a 14.2SP1 ISO, he could incorporate installer changes, provide a newer kernel series and maybe even update mesa (although, that could add a lot of extra upgraded packages depending on what version he'd go to and the other dependencies that might need to be upgraded) or some of the video drivers.

The benefits are definitely there, but it would require additional work on Pat's end. Especially if he were wanting to support both the original 14.2 and the SP1 packages. It could also have ramifications on 3rd-party repos if the base packages were changed enough (but if it were just the kernel and installer, very few 3rd-party packages/SlackBuilds would need to be modified). Whether the benefits are worth the extra work can only be decided by Pat.

I'll let Darth speak for himself about SP1. My proposal is clearly to have the same packages in the new ISO as in Slackware-stable at time of release of the new ISO. If a package is upgraded on the occasion it will go in /patches in the packages repository for the stable release. Pat really should not have to handle a new packages repository every six months or year.

About kernel upgrades: there have been several for security fixes in Slackware 14.2 already, but still in the 4.4 series. I don't know if upgrading to 4.x.y with x > 4 would be acceptable for Pat and have no advice to provide on that topic.

About mesa or other changes of packages on which others depend (but for security fixes), in my humble opinion and for consistency, either Pat finds acceptable to provide upgraded packages in /patches or they shouldn't be shipped in a further ISO for the stable release.

What happened to Slackware 14.2 users who actually understand their system and are able to upgrade any software they need by compiling from source? Or even better, from the SlackBuild script provided in the Slackware-current source tree. Appeltje Eitje.

Service Packs are only a stop-gap for "people with no internet access", and what happens after the next public security update? Those people will have to access the Internet to get those patches. And while they are disconnected from said Internet, there should not be any chance of getting hacked anyway.

Too many people in this forum somehow have donned a corporate hat and suddenly can not think any longer of Slackware as a tool for smart people.

I have no problems with this and I was able to successfully install 14.2 onto my NVMe drive without having instructions available at the time (although, the installer and eliloconfig had already been updated in -current, so I was able to use those).

I don't see much benefit of including all the patches onto a newer disc other than saving some downloading of patches after installation. And I've certainly pulled my share of SlackBuilds from -current to upgrade various pieces of software (or even beyond the versions included in -current). And with 55020's dusk builds available, it's never been easier to upgrade a kernel.

But, IMO, lack of NVMe support in the installer is quite the barrier for some and the kernel included on the disk might not work with the latest hardware (can't remember if I've seen issues with this on the forum, but it is still possible). Sure, maybe Pat's not interested in people who can't work that out, but I can't answer that for him. I was just providing some reasons on why it might be beneficial for a release including an updated installer and better support for modern hardware. I can't even say that I'd prefer having an SP1 or similar, just that I do see some benefits of offering it.

I do not think that a Service Pack will change something major for the people who are able to upgrade any software they need, compared with the usage of stock release with the security patches applied.

Because that Service Pack will contains integrated those security patches and a more modern LTS kernel with its fleet of associated packages, e.g. e2fsprogs.

I do not think that the Service Packs are only for those from North Korea (which I suggested as example)

It is a way of having a modernized and security enhanced Slackware release. And a way to do (small) releases often, then keeping the pace with the computers world changes.

Being here, I believe that Patrick does not need to continue to maintain both of the previous/major release and its Service Packs. Because essentially they are security patches.

And after the next security update, the business will be as usual. After all, the Service Packs will contains the already applied security updates.

Let's do not antagonize the rookies or those who have no time to do Slack-fu with the "smart people"

And I do not think there's something like a "corporate hat", but just a way to have updated releases often.

Ok, I'll stick with your argument of NVMe being universally available in the EU. Unfortunately at this time PV doesn't include support in "stable" for NVMe, per Didier. That would mean, if the Service Pack included drivers and a modified installation process for NVMe, that the Service Pack is a derivative of 'stable" and more work for PV to figure out how to integrate it into the DVD release. Sounds like a point release of 'stable'. Wouldn't you agree?

It could be useful to have an option for "Small" installation as well which installs just one of every application (most preferrably lightweight or console) and remove all KDE games(and other games), other not needed KDE applications to make the install lean and efficient for those who need/want this.

Here you have the tools to create any install option you want.


Cheers

Again, I am not Darth but... In the case of NVMe the only needed change are these patches[1], applied to Slackware-current which are transparent for the user and need no change in the kernel's configuration or firmware.

Handling eMMC IIRC would need some changes in the kernel's configuration in addition.

But let's not a tree hide the forest, as we say here: any specific case should be handled specifically.

If you agree let's agree to disagree, not to encumber this thread anymore with our respective arguments.

[1]As an aside I have since found a simpler and hopefully more general logic to detect EFI partitions on any kind of device.

While I do plan to make some use of the UUID detection method, I found that many of the fdisk programs on Linux don't properly create the standardized UUID for an EFI System Partition. In particular, gdisk (which is recommended in README_UEFI) does not, while fdisk and cfdisk do follow the standard.

I am sorry, but where do these uninformed rookies come from? Are they the people who jumped ship when their hand-holding distro adopted systemd?
And I have no patience for people "who have no time" to learn Slackware properly. For them, there probably are better distros than Slackware.

Last time I looked, Slackware "is ready when it's ready". There was no newspost that I know of, stating that Slackware now follows corporate strategies. But perhaps, I missed the memo.

My $0.02 regarding the .new file handling: yes, it is a burden (especially if you have to do it on more than one machine), but I like knowing that $prog-X.Y+1 has now new "Foo", "Bar" and "Baz" configuration options in the default config.

What I don't like however, is to spend my time reviewing .new files where the only change is because /usr/doc/prog-X.Y is now /usr/doc/prog-X.Y+1 (hi, /etc/mutt/Muttrc). It would be really cool if programs like this could use /usr/doc/prog symlinked to current /usr/doc/prog-X.Y and then config file would refer to /usr/doc/prog - the same way n/postfix does it now.

The new (2.90) sysvinit might be looking up to systemd and trying to be smarter than the admin... Turns out it automatically tries to spawn /sbin/agetty if it finds "console=..." in /proc/cmdline - even when there's no mention of gettys in /etc/inittab.

This creates unnecessary noise in environments like LXC containers for example. /proc/cmdline inside container is exactly like on the host, with (in my case it might be) "console=ttyS0 console=tty2" or similar. So on each such container, init endlessly spawns /sbin/agetty, they don't have a device to stick to so they exit, so init respawns them, then stops for 5 minutes, then starts again... eh :)

Oh, did I mention that /sbin/agetty - both path and options - are hardcoded in src/init.c?

In case anyone wants their pkgtools to work this way for handling .new files, I ended up implementing it as a mod to installpkg, not slackpkg as I originally was thinking. In addition to the patch I posted before, I also added some code in installpkg that overwrites the existing config() function in any doinst.sh files. The patched versions are available here:

https://github.com/montagdude/SlackB...ystem/pkgtools

The easiest way to get it would be to just clone the whole repository and then go to SlackBuilds/system/pkgtools and run pkgtools.SlackBuild. The first time you upgrade or reinstall a package with this new set of pkgtools, it will revert to the old behavior, because there will be no .ref file yet. Subsequently, the modified behavior will be used.

Edit: I have been using it without any issues for a few days, but of course there are no guarantees, so don't blame me if it messes something up. :)

Edit 2: This is based on pkgtools for 14.2. I haven't checked if the code has changed for -current, but I'm sure this mod would be equally easy to implement either way.

The whole discussion about service packs is just beating around the bush of the real elephant in the room: Slackware 14.2 has been released two years ago. I have always been on -current and despite never following any of the instructions regarding updating packages (e.g. about doing it in single user mode or which packages should be updated first) I have never had any problems with it. I’m seriously baffled why a new release cannot be ‘trivially’ cut from -current every six months.

Perhaps from Windows or Mac.

This is just elitism. No, Eric, using Slackware does not make you smarter than people who use other distributions. If a user cannot install Slackware from the latest stable release ISO because that release does not support their hardware, that’s not failure of the user; that’s a failure of Slackware.

Well if you mean providing an ISO as a snapshot of the -current tree, AlienBob already provides it daily or so, for instance here. But not every new Slackware user wants to run -current, and this cut won't provide a "ready as stable" state until the next stable release.

Because the whole development thrust of -current is to create a new stable release that is well-tested and as free from errors as possible. It is not a rolling release model where a new "stable" release can be "trivially" cut at any time.

I don't want to get too off-topic, nor do I want to start a flame war, but I disagree that Eric's opinion is elitism. That opinion holds true for other things as well. Here's an example: I primarily write code in C (not really). One day I decide I'll start writing code in Ruby, but I'm admittedly lazy and don't feel like learning Ruby's idioms. I try to write a block of code as I would in C, but it doesn't work, or performs sub-optimally. I blame Ruby for not supporting that way of writing that particular block and think it is a bad language.

So is it Ruby's fault for not supporting a particular way of doing something, or is it my fault for not learning "the Ruby way?" I think that is what Eric means when he says he has no patience for people "who have no time" to learn Slackware properly.

I am puzzled. I just tested (admittedly with a very limited scope) fdisk and cfdisk (both with dos as well as gpt disklabels), gdisk and cgdisk as well as parted (but parted doesn't allow to explicitly set the partition type so is useless in this case: only the future file system can be set and not surprisingly this leads to the partition GUID associated to a "Microsoft data partition" if set to fat32). I have not tested sfdisk and sgdisk yet.

I tested with a small USB stick fully zeroed with dd before each try, and checked the results with lsblk.

The summary of the test results is reproduced below:The UEFI specification states that an EFI System partition has a GUID of C12A7328-F81F-11D2-BA4B-00A0C93EC93B for a GPT layout; and that in case of a DOS layout instead, an ESP should have an OS type of 0xEF. lsblk writes these values in the same field PARTTYPE.

As you can see, parted put aside, all tests done show the good partition type or OS type, thus lsblk could be used to find the EFI partitions, if I am not mistaken. That's what I do in EFI3M:
Do I miss something? Or should I made other tests, like modifying a partition table instead of creating a new one?

I attach the log of my tests with gdisk (I also installed a FAT file system and changed the partition GUID, which as expected didn't change the partition type GUID).

We are still running Grumpy Old Man Linux! I don't know that your comment was all that "helpful", I clicked because it made me LOL again. Thanks.

I'd rather not be updating a "stable" kernel every few days myself, that is not what I call stable. I don't know what Pat is planning for Current kernel versions, the updates are too frequent for my tastes.

Just in case anyone forget, I am the one who complained about a way to pay for Slackware with a paper check. I did mail it that day I commented about a month ago, but maybe the USPS has become horrible too, or the banks can't agree how to process it, or maybe Pat just hasn't taken it to a deposit station. I don't know.

My ignore list wants to grow every time I log in here lately, eternal september makes me GROUCHY so thanks LQ for cramming one useful USENET option through port 80. Cheers

Everyone should remember there was a time when they were also rookies. I don't recommend people who don't have patience for beginners to have young children. I recon that new comers have to do some efforts, but those who have experience have to help others without contempt. If they don't have time to do it, none forces them to participate to a thread. When I don't feel competent upon a subject, I don't participate to it, nothing more. I wouldn't stay and appreciate that forum if every time I asked for an advice the answer was : RTFM, that's not my philosophy of linux, and of linuxquestions Slackware forum..

IMHO, consider also that RTFM ("reading the fine manual") more often than not can clarify issues much better than a short answer on a forum.

Slackware-current is not a "stable release". Frequent kernel updates are part of getting the next release to a stable state. If you don't like those frequent kernel updates you can simply blacklist the kernel packages and stick with one of the older kernels. You could also consider reverting to Slackware 14.2 to get back a feeling of stability.

Have you ever observed frequent releases of new kernels in any stable release of Slackware? Indeed, no.

In fact, I am very patient with rookies/newbies in Slackware. As long as they show a willingness to learn and are doing their own research in addition to getting answers to their questions in this forum and other places. Look back at my older posts, check out the comment sections of my blog posts. People who ask intelligent questions get a relevant answer. People who act stupid get what they ask for.

I suppose you read my post entirely the wrong way. I was referring to those new users of Slackware who do not have the patience to learn about the OS they switched to and instead want everything to "just work". Slackware is not for that category of people.

I appreciate this post.

I like this idea. Perhaps each new ISO could be called something like 14.2-1, 14.2-2, etc. I think this idea ties well into Pat's request for suggestions.

I maintain a local repo of the Slackware mirrors. I created a shell script that creates a new ISO that includes the /patches tree. I update the ISO image when my local repo updates. With respect to new installation though, there is no option to "slip stream" the /patches packages directly into the installation. If I performed a fresh install this way I would have the /patches packages handy but would need to manually install.

If Pat decided to support incremental ISO images for the stable release then an automatic method is needed to install the /patches packages. Just my two pennies. :)

Debian has an approximate three year cycle. Ubuntu five year. Red Hat and Suse 10 year. Before Windows 10 I think the release cycle averaged about three years.

Two years might seem long compared to previous Slackware release cycles, but operating systems are now far more complex and expected to provide far more features. I like slow changes. I also expect Pat to have a life outside of Slackware. For me, Pat's development pace is just fine. :)

If I wanted bleeding edge or rolling release I would use Current. Or something like Arch or Fedora. Or compile all of my own packages. :)

Sadly, there is a long history of elitism and RTFM in the Slackware community. Old time Slackers might recall the usenet list. That was a cruel and harsh place for any Slackware newcomer.

That mantra about the "Slackware Way" long ago got old and tiresome. Monkeys throwing poop, etc.

Where I work I don't have to often deal with the customers, but quite often I watch those in the company who do. The customers are, generally, overwhelmingly non technical and computer illiterate. I am amazed with the utter patience offered by the employees who deal with the customers. So much so that I am somewhat ashamed at my own impatience. Most of the customers are good decent people. Smart and intelligent and knowledgeable about other topics. Moms, dads, grandmas, grandpas. Just ordinary people. They are just not into computers. When I observe the other employees working with customers I wonder what happened to my own compassion for fellow humans.

I would never dream of treating children with such an attitude. Yet in this forum contempt is deemed okay when dealing with people new to computers or Slackware.

Recently there was a flurry of suggestions from many people wanting to help Pat with suggestions. Perhaps one of the suggestions could be to leave elitist attitudes at the door. Such attitudes likely are a contributing reason Slackware has declined in popularity. :(

Those of us who like to tinker "under the hood" with respect to computers are now, very much, a distinct minority. We no longer are the norm as we once were in the original heyday of computers. The remainder of the population want computers that are easy to use, no questions asked. Slackware is usable by those of us who tinker, but is not usable but the mainstream population.

Many of the suggestions offered the past many weeks are about nudging Slackware toward mainstream usage. Understandably, such suggestions tend to upset some Slackware users.

I like the overall Slackware design. Yet if Pat -- in his open plea for suggestions -- wants to target computer enthusiasts only then that message should be clear on the Slackware web site. If Pat wants to target non technical or enterprise users -- to which he hinted the possibility, then changes are needed with Slackware. Slackware as-is cannot satisfy the requirements or expectations of such users. I'll keep using Slackware one way or another. I just think Pat should be clear about the target audience so there is no confusion. :)

Instead, in the incremental ISO, just replace the packages in /slackware or /slackware64 by those in /patches, case occurring. Just my 0.02 € ;)

Nah, he'll wait for another hole in his roof. Slacking is addictive :D


Cheers.

Yes, of course. :) But raises a question: Does the /patches directory still need to be populated (duplicated)? The change log explicitly identifies the patched packages by directory (patches/packages/*). That's somewhat why I suggested the installer be modified to install the /patches packages. No "slip streaming" involved and the user gets the latest packages installed locally rather than from online.

Which raises another point. The /patches directory always has been real-time. That is, only the most recent version of a patched package is included. Although rare, occasionally somebody needs to revert a patched package update. Currently Slackware provides no easy method to support that, which is important for enterprise users.

I have worked around this shortcoming because my backup strategy includes the /patches directory but not the remainder of my local repo mirror. I can rebuild my local repo mirror with rsync, but not the older /patches packages. I started this practice many years ago because of an obtuse bug in the Samba package that killed my connections. A fresh upstream Samba package arrived in a couple of days but during the interim I had to scramble to find the previous package version.

This is not an unknown challenge. Several times Pat has reverted packages in Current because something breaks.

Perhaps the main Slackware repo could be modified to retain older /patches packages in /pasture. Perhaps /pasture/patches? That also would include kernel packages.

I think only yum supports a direct way to reverse package history. I support CentOS at work and do not particularly care for the distro, but this reversal feature is valuable. Even the venerable Debian provides no such reversal mechanism. If replaced packages are stored somewhere in the master repo such as /pasture, at least users have a way to restore that rare botched update. Or, when bisecting bugs, have a way to easily find older packages.

If such an idea was adopted, slackpkg and slapt-get could be modified to support reverting packages to a previous version. Some sweat equity involved for all of us to test such a feature, but I think this would be much welcomed by many people. :)

Can't you just set DELALL=off in /etc/slackpkg/slackpkg.conf?

That might be a sane starting point, but the option affects only the local slackpkg cache. Doesn't help slapt-get users, users who only use the base package tool commands, or users searching the mirrors for older packages. :)

You said:

But that is false, because slackpkg is included in Slackware, and it provides an easy method to do just what you are asking for. slapt-get is not part of Slackware.

Slackware doesn't intend to keep older patches available. Each patch replaces older ones. A solid admin wouldn't be rolling out patches without testing and without keeping an old copy available in case testing didn't uncover issues that happen in production.

I also don't think that slackpkg has the ability to keep things upgraded properly if multiple versions of the same package are available under the patches/ directory, however, I've never thought to test this.

That being said, there is a mirror out there that keeps all the older versions, allowing you to easily downgrade to previous versions.

http://slackmirror.cbpf.br/pub/slackware/

As an aside, here is how Arch Linux handles its archives:
https://wiki.archlinux.org/index.php/Arch_Linux_Archive
https://archive.archlinux.org/
Caveat: I am not requesting that Slackware do the same thing.

My experience and observation is issues rarely surface immediately but tend to pop up days or weeks later. Tough to test that kind of thing. :)

Would seem so, if DELALL=off is enabled. I think the default behavior is DELALL=on. Until today I never knew about and had never used the feature. Possibly because I maintain a local repo, which I started supporting before slackpkg was absorbed into Slackware. I never had a reason to investigate that option. :)

Fai enough. I included the reference because many suggestions of late focus on improving Slackware. Improvement is subjective of course, but repeatedly two aspects are raised in those discussions: 1) lack of dependency checking when installing packages and 2) lack of a large central repo. slackpkg does not support dependency checking. Some third-party tools do, of which one is slapt-get. Several people have suggested to Pat to include slapt-get in /extra.

Pat openly requested suggestions. This specific thread is about Current, where many of those suggestions likely would be tested, if at all.

Possibly that is how the main Slackware repo could be maintained. Actually, I think that is a great idea. :) Would be interesting if somebody tested whether slackpkg can handle multiple versions of the same package in /patches.

ImageMagick-6.9.10.11
https://www.imagemagick.org/download...9.10-11.tar.xz