[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.
Ok, I close my eyes (won't google) and ask kindly: what does canatakana - oh man - cantankerous mean? How do you spell that? Does it polite to tell: you are cabatkana - oh man - cantankerous person?
Thanks for the explanation. I have a relative that may end up using Slint on their old core 2 duo laptop when Slackware 15 comes out. Their vision isn't what it used to be and they say they want to learn to install and administer Slackware.
Slint includes the MATE desktop (among others) with the Compiz windows manager which provides a handy feature called eZoom http://slackware.uk/slint/x86_64/sli...pizKeyBindings, and other features useful for folks with a low vision, like fbterm which allows to have an arbitrary big font on the console. Caveat: installation needs 2G of RAM. But after installation swapinzram can make a low spec machine a lot more responsive. You can check installing it in a VM, preferably in Auto installation mode. Using eZoom when typing in a terminal or editor with magnification, that's the window that moves horizontally, so that the cursor stays roughly in the middle of the screen.
Last edited by Didier Spaier; 04-07-2021 at 04:38 AM.
Maybe just use one of the BSDs, then? But this brings up a good point re: Linux vs. BSD. What is the "core system" of Linux? The kernel? The userland tools? Both of these combined?
I'd like to use a BSD, but some of the things I do require Linux :/ I'd personally define the core system as the kernel + "essential" userland tools, though in Slackware's case it's everything that's included in it.
Quote:
Originally Posted by ppr:kut
Alright, I'll humor you.
Dependency checking shouldn't be viewed as a feature, but a solution to a perceived problem of system administrators. In essence, what you want is not dependency checking per se, what you want is a solution to one of these:
- When I install a package, I want what I need from it to work
- When I uninstall a package, I want it to not break something else I need that's still installed
Perhaps there's some more scenarios, but I guess those are the two most common ones.
Just doing dependency checking the way debian/fedora/etc do it isn't gonna solve that problem. It works for them (for a variable degree of "works") because they make sure the "what I need from it" and "something else I need" parts of a package are sufficiently small so an automatic system can make safe assumptions here.
I.e. there's a package for "php-mysql" and all it does is provide mysql support to php. It doesn't provide anything else. If you remove a "mysql-libs" package, it's save to say that it would break "php-mysql" since it needs the mysql libraries to connect to mysql. And same the other way around, if I install "php-mysql" it's save to say that I'm gonna need "mysql-libs" because that's the singular purpose of what I'm trying to install. (this still isn't entirely true, but it's close enough to illustrate the point, I hope).
This doesn't work with slackware's packages because they are "too big". But that too is a solution to a problem, specifically
- When I install this package, I want everything that I could possibly associate with that package to be installed. I don't want to have to hunt down lib X provided in a different package Y
- When I create a package for "foo", I don't want to have to figure out how to split this up into smaller pieces.
So inherently, one solution is in conflict with the other and you can't have both.
How to solve this? Well, you go back to the roots and try to solve the first problem in a way that doesn't conflict with slackware's package sizes. This is where things are gonna get iffy for you. You obviously care about disk space enough to not want something unnecessary installed on your system. By that reason you'll probably also not like to have things in a package that you don't need. If that's the solution you're looking for, then I'm afraid, I'll have to point you to Debian/Fedora/etc because it's just relatively unlikely to happen here.
But let's assume that's not the case, then you'd have to take a look at how else this could be solved. So let me throw some ideas around:
Slackware doesn't provide solutions, it provides tools for the Admin to come up with his own solutions. So however dependency checking would look like, it would need to follow that mantra. It should still be possible to use installpkg, removepkg, slackpkg etc without having to worry about dependencies. I want to shoot myself in the foot and either one of them should just happily hand me the gun and let me do it.
What you'd probably look for is a database of dependency information than can be queried. Perhaps by something called "infopkg" you can run after installpkg/before removepkg that shows you what the package "interacts with" ("depends on" is such strong wording). Perhaps this even shows you why it interacts with certain other packages so you can make informed decisions on whether you'd need/want them or not.
This would probably work "ok", but falls apart when you mix packages from different repos that were built with different assumptions. Such a use case would come with a whole new set of complications, since then the system can't be based on package names. That's where my insight into these problems ends, however, so how to adequately verify that package "foo" actually provides "libbar" in a version and configuration that works for package "baz" is up in the air. And then you'd also have to think about how that information is gathered. How would this would work for non-binary packages, python, perl, ruby, etc.
I've barely touched the surface of this and already this looks like a rather daunting task, probably equivalent to a phd thesis. Or two. And I can promise you that while some of those challenges would overlap with what Debian/Fedora/etc face, not all of them are solved yet there either.
So, there you have it, my 2 cents. Enjoy. I know I did
Fair enough. My simple solution would just to be "grab whatever's required, don't touch it from then on and let the admin deal with removing dependencies." If you need to know what an installed package depends on and/or what packages depend on that package, you'll just run some sort of utility (maybe the infopkg you described?) that lists what depends on what. It'll probably end up being a mess, but at least removepkg will only bring down the package itself rather than the package + its dependencies + packages that depend on it.
Quote:
Originally Posted by bassmadrigal
Generally when we see someone with a new account posting something controversial, it's from a troll.
Why does Slackware need to be more like the BSDs? Slackware is not a BSD, even if part of the init is borrowed from BSD. So many people come to Slackware and want to change it to be more like X distro. Why not just use X distro?
You actually didn't. Maybe it was implied in your text, but it certainly wasn't explicit. See below:
======================================
All this being said, it seems like what you're looking for already exists. A small core distro with dependency resolution based on Slackware. This is what Salix is.
I didn't see it that way (but then it wasn't directed at me, so maybe I'd see it differently if it was). rkelsen basically stated that there is not one ideal Linux distro. I don't like using Debian, but for some, Debian is their ideal distro. I have no desire to try and get Debian to change to be more like what I like from Slackware.
It's good to have different distros tackle things in different ways. If you don't like how one distro handles things and prefer how another distro handles things, there's nothing wrong with that. That was what I took from rkelsen's post.
I think it's silly to assume that someone's trolling just because a) their account is new, and b) they have an opinion about something that's controversial. Doesn't exactly lead to the best replies, as can be seen in most of this thread.
Yeah, I didn't really make it explicit what I meant; sorry. I tend to have a hard time expressing myself sometimes, so things like that happen on a semi-regular basis.
Distros shouldn't change just because they're different from other distros, but adding some sort of dependency resolution, either as a separate tool or as a part of installpkg, won't magically turn Slackware into a Debian or into a Fedora. It'll still be Slackware.
Quote:
Originally Posted by RadicalDreamer
Because people come on all the time and do 1 post that is insulting and are never to be seen again, and then people keep on replying to the bait ad nauseam. How would you like to be referred to as "horrifically archaic?" If you don't want xf86, xorg, xfce, or kde then you can remove them easily with slackpkg by using
Code:
slackpkg remove
People that want Slackware and dependency resolution can use Salix! "Salix, like most distros (but not Slackware) provides full dependency management, which means that any items the package needs to run are installed too -- and also that they are guaranteed to be available." http://guide.salixos.org/31PackageManagement.html#4_1
I literally haven't insulted anyone, though; I've criticized Slackware's pkgtools. If people take that personally, well, that's hardly my problem.
Yes, you can just remove xorg, xfce, kde etc., but you have no idea if you're going to break another package by doing that.
Salix looks a bit sketchy on the outside (being sponsored by online casinos isn't exactly a great look), but I guess you shouldn't be judging a book by its cover, eh? I still believe that dependency resolution should be part of Slackware one way or another (as a separate tool or as a part of installpkg); Salix shouldn't need to exist from my point-of-view.
Quote:
Originally Posted by svim
OK, so even if you're not just trolling it's still a matter where your mindset is too limited to accept the fact that every Linux distro just isn't going to fit in with your particular needs. Basically you're trying to force Slackware to be something it isn't, and for your own reasons you're also having a hard time accepting that as a reality.
Personally, I prefer Slackware as is, it's a distro that makes me think about what I'm doing when installing some obscure utility with a bunch of dependencies -- I learn more in the whole process and have a deeper level of comprehension to troubleshoot my own problems that might occur later. But that is just my preference.The thing is, we all have different reasons to make our own choices so not being able to accept that Slackware is fine for some but not for yourself shouldn't be such a contentious matter that you're trying to make it be.
I'm not trying to turn Slackware into another Debian, Fedora etc. etc.; I just want to be able to manage the system sanely by knowing what depends on what, and I believe others should be *able* to do it, too.
Quote:
Originally Posted by SqdnGuns
Looks like the quarterly Troll post bitching about Slackware.
Don't like it, don't use it. Plenty of distros out there but you seem to be best suited for Windows Dev Builds.
I like Slackware, I just don't like pkgtools' lack of dependency resolution. I'm not trolling and saying "hey don't use Slackware it doesn't have dependency resolution!!!"; I recognize that one of Slackware's strengths is the lack of dependency resolution (i.e. you can remove a package without bringing down something else with it), but I just find the complete lack of it (as a tool or as part of installpkg) to be silly.
Also, ad hominen doesn't exactly contribute to discussions, so maybe you should knock it off.
Quote:
Originally Posted by rkelsen
I should be working, but I really can't stop thinking about this thread and the issue at it's core.
I'm quoting Eric again, because this really hits the nail on the head. You're a wise man Eric, and your (profound!) post here really condenses the issue down to it's essence.
I can't help but wonder if the attitude hinted toward by Eric above has been created by Apple and Microsoft slowly and surely over the past 3 decades. For most of that period of time, both of those companies have created software which actively prevents administrators from making catastrophic mistakes. Therefore, it logically follows that the concept that with Slackware we have a system that by it's very design holds the administrator accountable for all of their actions must be quite scary to some.
On a slight tangent, this thread makes me think of the piano. I don't know how to play the piano... but I don't go around complaining that the design of the piano is too complicated and that it should be made simpler. It doesn't bother me that others know how to play the piano whilst I don't, and I admire and respect people who can and have clearly invested the time and effort it takes to learn how to do it well.
I don't see how dependency resolution doesn't make admins accountable for stupid mistakes, it just makes their life perhaps a tad easier.
I know how to use Slackware (used it as my main distro for about half a year, and as my second go-to distro for another half-year), and the reason why I even made this thread in the first place is because I like Slackware; I just happen to dislike pkgtools' lack of dependency resolution (and, well, how large Slackware's core is). A pianist can still complain that the piano is complicated, y'know.
Quote:
Originally Posted by fido_dogstoyevsky
At last, at last!
I can finally answer, without any sarcasm:
It's a feature, not a bug.
If you don't like it, you can either use something like slapt-get or try another distro. Not telling you to get off my lawn, just that I don't see it as a problem; if it is a problem for you, there are ways of fixing it.
slapt-get only partly solves the problem; you still have the problem of having a large core system without any way to sanely manage it. Seems like that's outside the scope of Slackware, though.
Last edited by gerogerigegege; 04-07-2021 at 04:49 AM.
Distribution: Slackware 15.0 x64, Slackware Live 15.0 x64
Posts: 618
Rep:
@OP...please, be happier using one of those other OS's you seem to think are far superior. No one is stopping you from doing so except you. It seems all you want though, is to make Slackware be like those others you won't/aren't/are-but-want-every-OS/distro-on-the-planet-to-be-like using. You seem to me the kind who would complain if a bottled water was brought to you and it wasn't the 'brand' you wanted and would complain anyway even if you found out that all of them are bottled at the same spigot.
Want Slackware to be like *you* want it to be? Go to LFS and start. Just don't come to Slackware and tell the man who created it that he's wrong and doing things badly and wrongly and needs to change it to the way another distro/OS is doing things. This distro must be doing *something* right to be the longest running/oldest distro still in use and upkeep.
Then you should appreciate it's simplicity and the power inherent in that simplicity.
Quote:
Originally Posted by gerogerigegege
(and, well, how large Slackware's core is)
There is no "Slackware core."
There is either Slackware or "cut-down Slackware."
Slackware is the entire set of 1,560 packages. If you're not installing them all, then it's a cut-down version. You will have an incomplete installation, and you will draw ire (and mockery) if you complain about stuff not working as intended.
This is a substantially different mentality to the Debian way of doing things. It may not be your preferred way of operating, but that's why there are different distributions. Your computer should operate in a manner you're comfortable with.
I don't know if you read Ruario's blog post which someone linked to earlier, but it really explains the Slackware philosophy quite well.
Then you should appreciate it's simplicity and the power inherent in that simplicity.
There is no "Slackware core."
There is either Slackware or "cut-down Slackware."
Slackware is the entire set of 1,560 packages. If you're not installing them all, then it's a cut-down version. You will have an incomplete installation, and you will draw ire (and mockery) if you complain about stuff not working as intended.
This is a substantially different mentality to the Debian way of doing things. It may not be your preferred way of operating, but that's why there are different distributions. Your computer should operate in a manner you're comfortable with.
I don't know if you read Ruario's blog post which someone linked to earlier, but it really explains the Slackware philosophy quite well.
Just because I know how to use it doesn't mean I can be critical of it.
The Slackware core *is* Slackware, that's what I referred to. It's the same idea as the BSDs, except that the BSDs are so minimal that there will never be a need to remove an included program. If you actually read my post(s), you'd know that I think that Slackware is such a behemoth that it's only sane that you'd want to remove a package or two, except that you can't because you don't know what's going to break.
Nothing mysterious - gero - in Latin - to achieve - most disturbing - GeGeGe - manga anime hero. People here are in reality much more friendly that it may looks like. Just perhaps unfortunate choice of word "horrible". Little too overemphasized. Slackware is not kind of orthodoxy. Just some are too much attached to their opinions. To defend it - to death almost. In past Slackware was aimed primary at Intel microprocessors. Imagine that . But past is past. People are doing many things around Slackware. To have optionally dependency resolution system - it is just nice option.
Last night's debate got me to speculating how I might introduce some degree of dependency management into a Slackware fork if I were a distro developer (which thank God I am not). I think it could be done in a limited way without destroying the essence of what Slackware is. This is what I came up with:
Nobody said it was taboo, as far as I recall. I discussed my view on this here.
Eh, I mean, just look at some of the replies to this thread.
Quote:
Originally Posted by hazel
You have been busy since I last came here!
Last night's debate got me to speculating how I might introduce some degree of dependency management into a Slackware fork if I were a distro developer (which thank God I am not). I think it could be done in a limited way without destroying the essence of what Slackware is. This is what I came up with:
That's pretty much how I imagine how Slackware with dependency checking would look like. This would be pretty similar to how the binary BSD package managers handle dependenices, too (afaik).
I have a little bit of time, so will address your points as best as I currently can, rkelsen.
Quote:
Originally Posted by rkelsen
You could not be more wrong there pal.
Which other categories are there? I can back up mine with examples, so if you could do similarly that would be helpful.
Quote:
Originally Posted by rkelsen
How old are we talking? I just updated to kernel 5.11.11 in about 2.5 minutes flat.
The kernel was the least problematic part, the other packages took the longest amount of time [as well as one or two dead repos] and using a "pure" Slackware installation is unrealistic, if not impractical, for most people.
Quote:
Originally Posted by rkelsen
Because you're a Debian user at heart.
I am not any OS user "at heart". I run machines with several different operating systems, Debian is just one of them.
Quote:
Originally Posted by rkelsen
You don't get Slackware and you never will.
This is just nonsensical, it's about relevance. I don't have the time or need to maintain a Slackware distro on my main machines at the moment. I have written several lengthy blog posts on Slackware and my learning of it. Of one, which addresses persistent naming in depth, you yourself wrote underneath:
Quote:
In choosing such a task, and seeing it through to the end you've earned your stripes, in my opinion. I can sense it. You're already a slacker through-and-through.
Welcome to Slackware! Or, more correctly, Welcome Home.
So do you now renege on your kind words? This is why I asked if your day was going well - such a criticism seemed a little out of character.
Quote:
Originally Posted by rkelsen
Slackware vs Debian is an age old fight.
I wasn't aware there was any such rivalry. Such a thing seems unfortunate and unnecessary.
Quote:
Originally Posted by rkelsen
How about: The whole system is on the iso. You don't need dependency resolution if you follow the recommendation and run a full install, because there is nothing to resolve. It has all been done for you.
See my second response above.
Quote:
Originally Posted by rkelsen
Does every Linux distribution have to be the same? Gawd, what a dystopian future you're aiming for.
Of course not, but Slackware will have to modernise somehow if it wants to appeal to a younger generation and get more users onboard going forward. This is not debatable. Look at Debian and Arch, both highly popular among young people. Slackware is not, because it, as well as its users, have a reputation for being too antiquated. If Slackware does not want to appeal to younger people, that is fine, but it has to accept that doing so increases its potential for dying out quicker [which it may be fine with - Slackware may prefer to break rather than bend].
Quote:
Originally Posted by rkelsen
"Here's a nickel, kid. Get yourself a better computer." - Condescending Unix user
A quote on the Slackware forum was either going to be from Dilbert or xkcd [the former being more likely given the context].
As I have said before, the Slackware forum, on the one hand, hates constructive criticism because Slackware is a highly conservative, traditionalist distribution. But, on the other hand, it also loves it because such criticism gives the userbase validation of its choice [note this topic is already into seven pages and will continue to grow].
So thank those members who come here and regularly say "is Slackware dead?" or "should Slackware automate dependencies?" because they're giving the forum a lot more reason to discuss and defend Slackware. Just don't be too hard on some of those posters: they may well have totally innocent intentions.
Last edited by Lysander666; 04-09-2021 at 04:34 AM.
Originally Posted by rkelsen
Slackware vs Debian is an age old fight.
I wasn't aware there was any such rivalry. Such a thing seems unfortunate and unnecessary.
That's fairly well known. Slackware derives ultimately from Soft Landing System, and Debian was created in opposition to SLS, which Debora and Ian Murdock strongly disliked.
Incidently, I visited https://slackware.uk yesterday after reading some of the posts in this thread and found that they supply SLS but only as floppy images. I wonder how you would go about installing it on a modern machine.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.