d@nny disc@hipsterelectron@circumstances.run
Oct 14, 2026, 3:02 PM@fiore @Lightfighter @TodePond hmmm @miss_rodent does it mostly just fetch/patch/install and work through the build system's dep discovery mechanism?
Replies
Vmiss_rodent@girlcock.clubOct 14, 2026, 3:07 PM@hipsterelectron @fiore @Lightfighter @TodePond Slackware's package managment is basically just scripts that shove files to where they're supposed to go;
If I install a binary package without the dependencies, all it's files are put in the appropriate directories, and it will fail to run b/c it tries to call something that doesn't exist.
For source builds like slackbuilds, it fails at compile b/c the dependencies were not found at build time.
It just ignores them - dependencies are my problem- Vmiss_rodent@girlcock.clubOct 14, 2026, 3:09 PM
@hipsterelectron @fiore @Lightfighter @TodePond (Some of the scripts can be written to check for dependencies and fail when they run if you want, but, *in general* the convention is to trust that the admin knows what they're doing.)
- Vmiss_rodent@girlcock.clubOct 14, 2026, 3:11 PM
@hipsterelectron @fiore @Lightfighter @TodePond There's some conveniences - like for an update it will tag new config files and let you decide if you want to overwrite the old config or keep the old one, or just deal with it later,
but, dependencies are a sysadmin problem. 
φfiore@brain.worm.pinkOct 14, 2026, 3:11 PM@miss_rodent @hipsterelectron @Lightfighter @TodePond that is . fascinating
- Vmiss_rodent@girlcock.clubOct 14, 2026, 3:15 PM
@fiore @hipsterelectron @Lightfighter @TodePond It's "simple" in terms of what it does - the package managment is just some shell scripts, the packages are just a tarball with an appropriate file hierarchy. Running 'installpkg' unpacks the tarball, copies everything to where it's supposed to go (binary to /usr/ config to /etc/, and so on), can do some things like validating a checksum and such, but, it's very basic.
So, simple in execution, but, assumes the admin knows what they are doing. - Vmiss_rodent@girlcock.clubOct 14, 2026, 3:20 PM
@fiore @hipsterelectron @Lightfighter @TodePond But the upside (for me, at least) is that... it doesn't do anything unexpected, doesn't grab a bunch of extra packages and install them, doesn't touch anything outside the scope of the package I am installing, and since it's all just shell scripts it's trivial to modify if I need, like, a packge installed to /opt/ or to ~/.local/ instead of /usr/ or some other weird local change.
- Vmiss_rodent@girlcock.clubOct 14, 2026, 3:21 PM
@fiore @hipsterelectron @Lightfighter @TodePond The downside, of course, is... that it assumes I know what I am doing. Which I *generally* do, but, that was not always the case, and is pretty often not the case for newer users.
LightfighterLightfighter@infosec.exchangeOct 14, 2026, 3:27 PM@miss_rodent @hipsterelectron @TodePond Dependency hell. The struggle is real.
- Vmiss_rodent@girlcock.clubOct 14, 2026, 3:33 PM
@Lightfighter @hipsterelectron @TodePond I mean... If you've used early versions of rpm and apt, especially in the early 00's, a common sort of dependency hell was things like having multiple packages in a repo which told the package manager it needed diffferent versions of the same library, and installing them could get you stuck in a case where *something* was always broken, or ciruclar dependency chains that could get the package managers tripping over their own tails and such...
- Vmiss_rodent@girlcock.clubOct 14, 2026, 3:35 PM
@Lightfighter @hipsterelectron @TodePond this is less of an issue nowadays, but, when slackware's package managment was first developed, it avoided a lot of these issues by just... not resolving dependencies automatically like that.
I still prefer it mainly as a consent/control over my own system thing, but, it was a practical option in the early days too. - d@nny disc@hipsterelectron@circumstances.runOct 14, 2026, 3:38 PM
@miss_rodent @Lightfighter @TodePond i have worked on several systems which avoid this and unfortunately the resolver needs to become much more complex to fix it paticularly since there is essentially no formal theory of this and most modern ones just fling shit at an SMT solver and let the user figure it out when it fails which is a terrible experience. i think what spack has is the best possible thing and they care a lot about user experience but i think we can do better
- Vmiss_rodent@girlcock.clubOct 14, 2026, 3:48 PM
@hipsterelectron @Lightfighter @TodePond Fair, don't mean to frame it as an easy or solved problem; it seems less of an issue nowadays on the user end for the big distro package managers (will defer to your judgement of how good current solutions are, it's a bit out of my scope), but, it was for a while a selling point of slackware's approach of 'You could just not." lol
- d@nny disc@hipsterelectron@circumstances.runOct 14, 2026, 3:50 PM
@miss_rodent @Lightfighter @TodePond noooooo i think it TOTALLY validates your position actually. i'm saying this as someome who loves graph theory and realizes the problem we want it to solve is very hard to parameterize
- Vmiss_rodent@girlcock.clubOct 14, 2026, 4:00 PM
@hipsterelectron @Lightfighter @TodePond Fair, yeah it seems like a difficult thing to manage - especially if you don't control the packages themselves (and thus, can't do things like, ensure no package specifies a *specific* version of a library, rather than "versions X or later", or that no packages depend on features/behaviours that were removed after some version, etc.)
- d@nny disc@hipsterelectron@circumstances.runOct 14, 2026, 3:15 PM
@fiore @miss_rodent @Lightfighter @TodePond RIGHT????