[SOLVED] Slackware's pkgtools is horrifically archaic, or why dependency checking shouldn't be considered to be taboo anymore
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.
Better is a such a relative thing though. There is usually a market space for 'inferior goods'. I might sometimes want the most delicious hamburger, there are other times when I don't have 45min to wait for it to be prepared and I just want something to scarf without getting out of my car. I am simply hungry I will be driving barely thinking about what I am even eating.
Same with Linux distros. Sometimes I want something any ape can keep running like Ubuntu to just host some web app front end. Other times I want confortable general use working environment that does not piss me off at every turn, so I pick Slackware even if it means I have to invest in some special knowledge to make it want I want it to be.
While I think we all understand "better" especially when "most delicious, most nutritious" are added, but my post was in no way to deny there is a valid market for cheap or convenient. It's just that in such cases what one gets is cheap and/or convenient instead of high quality. That is sometimes a valid choice but it doesn't mean the best always rises to the most popular or profitable and often precludes it.
I used to make jokes about how uneasy it must be for astronauts sitting on top of essentially a bomb with a hole at one end built by the lowest bidder... then Challenger happened. I don't joke much about that anymore but thankfully there is now SpaceX depending a lot less on cost-cutting low bidders.
After much thought I chose for the root (/) file system to use f2fs in Auto mode during Slint installation only for flash devices firmly attached to the computer, so SD card in a built-in card reader or eMMC drives, not USB sticks or SD cards in an USB enclosure, as I have read reports of corrupted F2FS in case the USB connection be bad and I don't know to which extent this has been solved.
I would probably do the same. I don't believe any hardware manages the wear-leveling on those types of devices, so I'd want a filesystem that is able to do it.
Wow! Cantankerous, Schadenfreude, and a Mozart/Salieri analogy... This thread is definitely flying higher that your average Slackware-is-dead thread
"dependencies" is proving to be a good thread seed!
Would it be time to start a systemd thread and see how it grows?
I think is still twenty years too early for a thread named "Slackware's init system is horrifically archaic, or why systemd shouldn't be considered to be taboo"
Last edited by LuckyCyborg; 04-08-2021 at 01:41 PM.
I've looked into different filesystems over the years, but it seems that there still isn't a clear choice on what filesystem is best to use with NAND based devices. Yes, F2FS may have been written from the ground up to work solely with NAND, where ext4 had support for NAND added in later, however, F2FS is not a clear winner in regards to performance. In this test from Phoronix about a year ago, ext4 had better performance in 13 of the tests vs F2FS outperforming ext4 in 9 of the tests. And similar performance has been seen in previous tests as well. Maybe there's some other aspects of F2FS that might be better that I'm not aware of, but performance-wise, there's no clear winner.
(I think I remember reading that F2FS may help deal with wear-leveling, which if that is true, it would likely be beneficial on portable devices like thumbdrives or sd cards, but for SSDs or NVMe devices, the controller handles all wear-leveling, so it wouldn't help with those types of devices.)
Fair enough, but there is also JFFS JFFS2 YAFFS UBIFS LogFS - but they are not enabled by default in Linux - I think at this point in time instead of waiting for another to write an FS solely for said devices, distros should now look into adding default support for those that are already available and installation on these types of FS for comparison and to see which is best for a NAND device.
I mean yea, you can also run BTRFS - but again that tries to replicate ZFS under a compatible GPL - and again ZFS was also written for conventional disks in mind.
About Salieri/Mozart: don't forget that Bach invented counterpoint, Haydn symphony and string quartet, Beethoven jazz (at least the swing), even if I am in a mood of listening Schubert.
About hamburgers and industrial food: My elder brother designed a machine able to kill 1000 chicken per hour. As he says: "chicken to sell, not chicken to eat".
Fair enough, but there is also JFFS JFFS2 YAFFS UBIFS LogFS - but they are not enabled by default in Linux - I think at this point in time instead of waiting for another to write an FS solely for said devices, distros should now look into adding default support for those that are already available and installation on these types of FS for comparison and to see which is best for a NAND device.
I mean yea, you can also run BTRFS - but again that tries to replicate ZFS under a compatible GPL - and again ZFS was also written for conventional disks in mind.
It would definitely be interesting to see benchmarks of the various filesystems and see how they stack up. And I'm definitely not against support for other filesystems being added to the installer (assuming they have been determined to be stable enough -- I don't know if I could recommend including support for alpha level filesystems).
It would definitely be interesting to see benchmarks of the various filesystems and see how they stack up. And I'm definitely not against support for other filesystems being added to the installer (assuming they have been determined to be stable enough -- I don't know if I could recommend including support for alpha level filesystems).
AFAIK all those that I have listed are not in alpha stage and are marked stable. Whether they should all be included right now, at best remains to be seen, but further down the line the decision should be made; because I just don't see running an SDD / NVME type disk on ext4 , or XFS , or BTRFS even with TRIM. It just would not make any sense other than sheer laziness but at the potential cost of your drive quickly down the line imo.
AFAIK all those that I have listed are not in alpha stage and are marked stable.
Good to know!
Quote:
Originally Posted by Jeebizz
Whether they should all be included right now, at best remains to be seen, but further down the line the decision should be made; because I just don't see running an SDD / NVME type disk on ext4 , or XFS , or BTRFS even with TRIM. It just would not make any sense other than sheer laziness but at the potential cost of your drive quickly down the line imo.
Almost all SSDs and NVMe drives have internal controllers that determine wear-leveling. The filesystem has no ability to override that wear-leveling, so I don't see how certain filesystems would allow your drive to wear down quicker than other filesystems. Now, if we're talking about sd cards, thumbdrives, or some devices with cheap internal memory (like 16GB of soldered on memory), then many of those don't have internal controllers handling wear leveling and certain filesystems could have massive benefits to keep the devices alive longer. I just don't see how it would matter with devices that include wear-leveling controllers.
Is there something I'm missing or have inaccurate information on?
I like not having dependency checking in the main distribution. It makes it much easier to build and install your own packages without causing the package manager to have a hissy fit. I don't even want to think about trying to install all the third party stuff that I like to build myself on something like Ubuntu. *shudder*
Sure, for most stuff you can find third party repos if it's not in the main distribution for Ubuntu, but then you have to take it as someone else decided to build it, and at their update pace. Slackware gives you more freedom.
Last edited by montagdude; 04-08-2021 at 07:05 PM.
I don't think deb2tgz ever existed in Slackware (but it is on SBo). I do stay away from deb2tgz and rpm2tgz (because of potential issues like this one). If I need to use an rpm or deb, I'll create my own script to extract the package and repackage it into a Slackware package (see my discord SlackBuild), ensuring permissions and file locations are accurate.
I do the same. If I have a choice between using a deb or rpm, I will choose the rpm.
Almost all SSDs and NVMe drives have internal controllers that determine wear-leveling. The filesystem has no ability to override that wear-leveling, so I don't see how certain filesystems would allow your drive to wear down quicker than other filesystems. Now, if we're talking about sd cards, thumbdrives, or some devices with cheap internal memory (like 16GB of soldered on memory), then many of those don't have internal controllers handling wear leveling and certain filesystems could have massive benefits to keep the devices alive longer. I just don't see how it would matter with devices that include wear-leveling controllers.
Is there something I'm missing or have inaccurate information on?
I don't know, but I like the extra assurance. I mean yea if there are those that would want to use something like ext4 or XFS fine - but I just like the idea of having a FS built from the ground up solely for said device. Thats me though.
I like not having dependency checking in the main distribution. It makes it much easier to build and install your own packages without causing the package manager to have a hissy fit. I don't even want to think about trying to install all the third party stuff that I like to build myself on something like Ubuntu. *shudder*
Sure, for most stuff you can find third party repos if it's not in the main distribution for Ubuntu, but then you have to take it as someone else decided to build it, and at their update pace. Slackware gives you more freedom.
So, the Slackware with its 1700 packages and no official way to extend it in other way than building software from sources (because the third party binary repositories are NOT supported) offers you more freedom than Debian with its 51000 official packages on the main distribution and myriads of third party binary repositories?
BTW, I testify you that IF your own local built packages contains no dependency information, both DPKG and RPM will install, upgrade or remove them with no further questions.
And YES, there is no auto-magic dependencies, you MUST specify them on your build scripts, IF you want this information to exists on your packages.
True, both DPKG and RPM will vehemently protest IF your own packages overrides files from other packages, BUT this is a separate "issue" if anything.
From what I know, overriding the files from other packages is seen by anyone others as a very bad habit and this overriding should NOT happen ever.
Last edited by LuckyCyborg; 04-09-2021 at 01:43 AM.
For me Slackware gives me more freedom in the sense that if I need to do something the hard way (e.g. compile and create a package from source) it is easier on Slackware than Debian. You want an example?
For me Slackware gives me more freedom in the sense that if I need to do something the hard way (e.g. compile and create a package from source) it is easier on Slackware than Debian.
That's subjective. It's just that you known better today the Slackware build scripts, compared with the way the build packages on Debian.
For me is similar easy to make packages for any Linux operating systems I use, be it Slackware, Ubuntu or openSUSE.
this is not found among the 51000 Debian packages. Of course, you are free to make your own .deb for it, go ahead.
Neither is found among the 1700 Slackware packages, and you give me as proof the build script distributed by an unofficial and un-endorsed project. Oh, well...
Probably, on Ubuntu this would be the equivalent of a PPA, BUT the Debian has even a Med Team...
Of course, IF ever I will need the Meme Suite on one my Ubuntu installations, I will build it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
