[SOLVED] Slackware's pkgtools is horrifically archaic, or why dependency checking shouldn't be considered to be taboo anymore

igadoter · 04-06-2021, 11:47 AM

@LuckyCyborg show us sometime mercy, please.

Edit: Do they talk about Slackware? https://youtu.be/GUwhnO-nTLo

ppr:kut · 04-06-2021, 11:47 AM

Quote:

Originally Posted by gerogerigegege

Slackware's pkgtools is, to be quite frank, horribly archaic; it doesn't have any sort of dependency checking, despite the fact that the core system is horrifically large (8GBs). Due to it not having dependency checking, you're not able to deselect any packages without risking breaking your entire system, so you'll just have lots and lots of packages that just waste space doing nothing. I've read quite a few posts on here where the conclusion ends up being "8GBs is not a whole lot of space", despite the fact that those 8 gigs could be used for something more useful. Naturally, this wouldn't be a problem if the core system was smaller (see the BSDs), but it isn't, so it's a problem.

Not even the SlackBuilds have dependency checking, despite the fact that all of the BSD ports trees have some sort of dependency checking; even the binary package tools on BSDs have dependency checking!

Dependency checking really shouldn't be viewed as taboo anymore; all of the (major) BSDs have it, and basically all */Linux distros have it. Even CRUX has it; even CRUX!

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

bassmadrigal · 04-06-2021, 11:50 AM

Quote:

Originally Posted by gerogerigegege

Bleh, why are you all assuming I'm trolling? Just because I think Slackware should do some things differently, and that thing just happens to be a controversial thing, doesn't mean I'm trolling; grow up. Differing opinions != trolling.

Generally when we see someone with a new account posting something controversial, it's from a troll.

Quote:

Originally Posted by gerogerigegege

I just think that Slackware should handle the core system and packages similar to how the major BSDs handle it (Free, Open, Net), i.e. have a small core system (either ultra-minimal like in the case of Free, or somewhat minimal with X like in the case of Net and Open) and have a sane package/ports system that has dependency checking.

--snip--

Dependency checking doesn't have to be some sort of over-complicated hell, just do it like how the BSDs do it.

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?

Quote:

Originally Posted by gerogerigegege

I explicitly stated that Slackware shouldn't check for dependencies in the core system if it was minimal

You actually didn't. Maybe it was implied in your text, but it certainly wasn't explicit. See below:

Quote:

Originally Posted by gerogerigegege

Naturally, this wouldn't be a problem if the core system was smaller (see the BSDs), but it isn't, so it's a problem.

======================================

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.

https://www.salixos.org/

There's no need to reinvent the wheel...

Quote:

Originally Posted by Lysander666

Well, that was something of a cantankerous post. Hope your day is going OK otherwise.

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.

LuckyCyborg · 04-06-2021, 12:00 PM

Quote:

Originally Posted by bassmadrigal

Slackware is not a BSD, even if part of the init is borrowed from BSD.

I thought that we already busted the myth that Slackware have the init system borrowed from BSD?

Looks like that the Slackware's init system has NOTHING in common with the BSDs - for details ask @ZhaoLin1457, I guess he will be happy to show you how BSD init scripts are for real.

elcore · 04-06-2021, 12:32 PM

Quote:

Originally Posted by gerogerigegege

Due to it not having dependency checking, you're not able to deselect any packages without risking breaking your entire system

Got 6 systems and only ever put one of them at risk, science people call it a controlled environment or something..
There's no dependency resolver in the world which can fix that one system, if I go out of my way to intentionally break it.
So, I guess you based this opinion on some sort of fantasy where everyone's at risk because everyone uses only one identical system with no backups.

bassmadrigal · 04-06-2021, 12:54 PM

Quote:

Originally Posted by LuckyCyborg

I thought that we already busted the myth that Slackware have the init system borrowed from BSD?

Looks like that the Slackware's init system has NOTHING in common with the BSDs - for details ask @ZhaoLin1457, I guess he will be happy to show you how BSD init scripts are for real.

*Sigh*

This is covered in the first line of this page:

Quote:

Slackware Linux uses the BSD-style file layout for its system initialization files.

BSD uses rc.PRGNAM scripts in an /etc/rc.d/ directory. SysV Init uses scripts in /etc/rc.{1-6}.d/ folders.

montagdude · 04-06-2021, 01:02 PM

Here's my symbolic vote to keep it like it is. If I wanted Slackware to be more like Ubuntu/Debian/Arch/BSD/etc., I'd just use Ubuntu/Debian/Arch/BSD/etc. instead. I have dependency resolution for SBo packages, which is really all that I need it for.

For those who really want Slackware with dependency resolution, there's Salix and a number of other derivatives.

LuckyCyborg · 04-06-2021, 01:16 PM

Quote:

Originally Posted by bassmadrigal

*Sigh*

This is covered in the first line of this page:

Code:

Slackware Linux uses the BSD-style file layout for its system initialization files.

BSD uses rc.PRGNAM scripts in an /etc/rc.d/ directory. SysV Init uses scripts in /etc/rc.{1-6}.d/ folders.

Oh, thank you for enlighten me! IF it's written this, it's so.

BUT, we have a single issue: apparently the BSDs put their main init scripts on /etc, at least according with the FreeBSD documentation, which do a cross-reference to NetBSD.

https://docs.freebsd.org/en/articles/rc-scripting/

Quote:

The historical BSD had a monolithic startup script, /etc/rc. It was invoked by init(8) at system boot time and performed all userland tasks required for multi-user operation: checking and mounting file systems, setting up the network, starting daemons, and so on. The precise list of tasks was not the same in every system; admins needed to customize it. With few exceptions, /etc/rc had to be modified, and true hackers liked it.

The real problem with the monolithic approach was that it provided no control over the individual components started from /etc/rc. For instance, /etc/rc could not restart a single daemon. The system admin had to find the daemon process by hand, kill it, wait until it actually exited, then browse through /etc/rc for the flags, and finally type the full command line to start the daemon again. The task would become even more difficult and prone to errors if the service to restart consisted of more than one daemon or demanded additional actions. In a few words, the single script failed to fulfil what scripts are for: to make the system admin’s life easier.

Later there was an attempt to split out some parts of /etc/rc for the sake of starting the most important subsystems separately. The notorious example was /etc/netstart to bring up networking. It did allow for accessing the network from single-user mode, but it did not integrate well into the automatic startup process because parts of its code needed to interleave with actions essentially unrelated to networking. That was why /etc/netstart mutated into /etc/rc.network. The latter was no longer an ordinary script; it comprised of large, tangled sh(1) functions called from /etc/rc at different stages of system startup. However, as the startup tasks grew diverse and sophisticated, the "quasi-modular" approach became even more of a drag than the monolithic /etc/rc had been.

Without a clean and well-designed framework, the startup scripts had to bend over backwards to satisfy the needs of rapidly developing BSD-based operating systems. It became obvious at last that more steps are necessary on the way to a fine-grained and extensible rc system. Thus BSD rc.d was born. Its acknowledged fathers were Luke Mewburn and the NetBSD community. Later it was imported into FreeBSD. Its name refers to the location of system scripts for individual services, which is in /etc/rc.d. Soon we will learn about more components of the rc.d system and see how the individual scripts are invoked.

The basic ideas behind BSD rc.d are fine modularity and code reuse. Fine modularity means that each basic "service" such as a system daemon or primitive startup task gets its own sh(1) script able to start the service, stop it, reload it, check its status. A particular action is chosen by the command-line argument to the script. The /etc/rc script still drives system startup, but now it merely invokes the smaller scripts one by one with the start argument. It is easy to perform shutdown tasks as well by running the same set of scripts with the stop argument, which is done by /etc/rc.shutdown. Note how closely this follows the Unix way of having a set of small specialized tools, each fulfilling its task as well as possible. Code reuse means that common operations are implemented as sh(1) functions and collected in /etc/rc.subr. Now a typical script can be just a few lines' worth of sh(1) code. Finally, an important part of the rc.d framework is rcorder(8), which helps /etc/rc to run the small scripts orderly with respect to dependencies between them. It can help /etc/rc.shutdown, too, because the proper order for the shutdown sequence is opposite to that of startup.

The BSD rc.d design is described in the original article by Luke Mewburn, and the rc.d components are documented in great detail in the respective manual pages. However, it might not appear obvious to an rc.d newbie how to tie the numerous bits and pieces together in order to create a well-styled script for a particular task. Therefore this article will try a different approach to describe rc.d. It will show which features should be used in a number of typical cases, and why. Note that this is not a how-to document because our aim is not at giving ready-made recipes, but at showing a few easy entrances into the rc.d realm. Neither is this article a replacement for the relevant manual pages. Do not hesitate to refer to them for more formal and complete documentation while reading this article.

There are prerequisites to understanding this article. First of all, you should be familiar with the sh(1) scripting language in order to master rc.d. In addition, you should know how the system performs userland startup and shutdown tasks, which is described in rc(8).

This article focuses on the FreeBSD branch of rc.d. Nevertheless, it may be useful to NetBSD developers, too, because the two branches of BSD rc.d not only share the same design but also stay similar in their aspects visible to script authors.

Please note that even historically talking, they claim that BSDs had in the past a monolithic /etc/rc init script.

Now, please enlighten me how I can run the following FreeBSD init script /etc/rc.d/foo on Slackware:

Code:

#!/bin/sh 

. /etc/rc.subr 

name="dummy" 
start_cmd="${name}_start" 
stop_cmd=":" 

dummy_start() 
{
	echo "Nothing started."
}

load_rc_config $name 
run_rc_command "$1"

According with you, it should be compatible with the Slackware's BSD-like init system, right?

bassmadrigal · 04-06-2021, 01:37 PM

Quote:

Originally Posted by LuckyCyborg

According with you, it should be compatible with the Slackware's BSD-like init system, right?

No, and I never said it was compatible with Slackware's init system. All I said is that part of the init system was borrowed from the BSDs, not that it was fully compatible with the BSD init system (which Slackware's docs don't claim either, although, it does claim compatibility with SysV).

Please stop putting words in my mouth.

I will admit that it seems I was mistaken that all startup scripts are rc.$PRGNAM. Only some include the rc. in front of the program's name and many don't. However, as far as I can tell, including functionality for start, stop, restart, etc is originally a BSDism and is not present with SysV scripts.

igadoter · 04-06-2021, 01:41 PM

@LuckyCyborg, @bassmadrigal - please stop. There is no winner in "Last Word is Mine" game. You are killing this thread.

Edit: There are interesting posts on subject in this thread. Just keep it this way.

LuckyCyborg · 04-06-2021, 01:44 PM

Quote:

Originally Posted by bassmadrigal

No, and I never said it was compatible with Slackware's init system. All I said is that part of the init system was borrowed from the BSDs, not that it was fully compatible with the BSD init system (which Slackware's docs don't claim either, although, it does claim compatibility with SysV).

Please stop putting words in my mouth.

I will admit that it seems I was mistaken that all startup scripts are rc.$PRGNAM. Only some include the rc. in front of the program's name and many don't. However, as far as I can tell, including functionality for start, stop, restart, etc is originally a BSDism and is not present with SysV scripts.

And there we go...

Fortunately, I known well what's about the SysV init scripts, thanks to Ubuntu.

So, start/stop/restart are BSDismes ?

Please take a look to this script:

Code:

#!/bin/sh
#
# <daemonname> <summary>
#
# chkconfig:   <default runlevel(s)> <start> <stop>
# description: <description, split multiple lines with \
#              a backslash>

### BEGIN INIT INFO
# Provides: 
# Required-Start: 
# Required-Stop: 
# Should-Start: 
# Should-Stop: 
# Default-Start: 
# Default-Stop: 
# Short-Description: 
# Description:      
### END INIT INFO

# Source function library.
. /etc/rc.d/init.d/functions

exec="/path/to/<daemonname>"
prog="<service name>"
config="<path to major config file>"

[ -e /etc/sysconfig/$prog ] && . /etc/sysconfig/$prog

lockfile=/var/lock/subsys/$prog

start() {
    [ -x $exec ] || exit 5
    [ -f $config ] || exit 6
    echo -n $"Starting $prog: "
    # if not running, start it up here, usually something like "daemon $exec"
    retval=$?
    echo
    [ $retval -eq 0 ] && touch $lockfile
    return $retval
}

stop() {
    echo -n $"Stopping $prog: "
    # stop it here, often "killproc $prog"
    retval=$?
    echo
    [ $retval -eq 0 ] && rm -f $lockfile
    return $retval
}

restart() {
    stop
    start
}

reload() {
    restart
}

force_reload() {
    restart
}

rh_status() {
    # run checks to determine if the service is running or use generic status
    status $prog
}

rh_status_q() {
    rh_status >/dev/null 2>&1
}


case "$1" in
    start)
        rh_status_q && exit 0
        $1
        ;;
    stop)
        rh_status_q || exit 0
        $1
        ;;
    restart)
        $1
        ;;
    reload)
        rh_status_q || exit 7
        $1
        ;;
    force-reload)
        force_reload
        ;;
    status)
        rh_status
        ;;
    condrestart|try-restart)
        rh_status_q || exit 0
        restart
        ;;
    *)
        echo $"Usage: $0 {start|stop|status|restart|condrestart|try-restart|reload|force-reload}"
        exit 2
esac
exit $?

Rings a bell for you? Right? Right?

BUT, I was borrowed this code from the Fedora documentation for EPEL's SysV init scripts:

https://fedoraproject.org/wiki/EPEL:SysVInitScripts

No matter how I look to those Slackware init scripts, they are just a "simplified" variant of the SysV init scripts.

In fact, probably someone can grab the /etc/rc.d/rc.httpd and put in /etc/rc.d/init.d/httpd and after populating the symlinks according with the runlevels, I bet that we can launch the Apache in the SysV init style, with no changes on the script code.

truepatriot76 · 04-06-2021, 01:44 PM

Quote:

Originally Posted by igadoter

@LuckyCyborg, @bassmadrigal - please stop. There is no winner in "Last Word is Mine" game. You are killing this thread.

Edit: There are interesting posts on subject in this thread. Just keep it this way.

Thread was already dead upon delivery.

RadicalDreamer · 04-06-2021, 01:45 PM

Quote:

Originally Posted by gerogerigegege

Bleh, why are you all assuming I'm trolling? Just because I think Slackware should do some things differently, and that thing just happens to be a controversial thing, doesn't mean I'm trolling; grow up. Differing opinions != trolling.

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

My understanding is that Slackel is like the Current version of Salix. Does it have dependency resolution? https://sourceforge.net/projects/slackel/

svim · 04-06-2021, 01:54 PM

Quote:

Originally Posted by gerogerigegege

Bleh, why are you all assuming I'm trolling? Just because I think Slackware should do some things differently, and that thing just happens to be a controversial thing, doesn't mean I'm trolling; grow up. Differing opinions != trolling.
....

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.

SqdnGuns · 04-06-2021, 02:09 PM

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.