User-centric package manager/linux distro

callmelou

New Member
Joined
Jan 24, 2024
Messages
1
Reaction score
0
Credits
31
So Linux is fantastic because you can do anything anyway you want and very conveniently with package managers and what not... but it is a hell-hole in a basket if you have no root privileges.

Linux distros (most notably RHEL) become even more of a bother to use when companies are running EOL distros and everything is outdated.
Everything becomes extremely limited in what you can do and all the vast majority of online answers start with 'so first install dependencies with sudo yum/rpm/apt ...'

Compiling from source is the only solution, which everyone always asks 'well why would you do that?' and you need to compile... EVERYTHING from source, including a new compiler when yours is so outdated.

After compiling several programs, I had to learn about several things important information for running/compiling programs (shared libraries, etc.) which is useful, but should NOT have to be necessary.

The only real challenge when compiling things is to make sure to link the right paths and everything is just automated, it's not THAT hard, just annoying AF, so, instead of relying of root-only system-level libraries, binaries, etc., why not allow a user-first mode where a user-owned directory (under user home or maybe a new /userbin /userlib etc). Basically like each user would have their own environment separate from the system and separate from other users. Root-installed binaries would operate independently and not be affected by user binaries/libraries.

So...why would anyone want this?
Obviously this isn't for the typical Linux users. This won't be useful for most because Linux users are the minority and most of them are their only user (and therefore the superuser).

HOWEVER! This would be best suited for future linux users, such as students(using school linux accounts), or engineers working with proprietary hardware that only works in....super old linux versions (fml).

Essentially, this mode would enable future students/employees to play with the system without the hassle of going through old forums and trying to compile old software to compile newer software to compile what they need. It's pointless other than "good to know" and slows you down when you're trying to be productive.

Having a user-centric mode would also be easier for Non-Linux users to install programs and keep their environment separate from their user accounts. They would not have to worry about breaking some dependencies if by default, this user mode was enabled.

So, am I crazy?
Is this a terrible idea?
Has this already been done and I'm just unlucky?
 


<snip>

The only real challenge when compiling things is to make sure to link the right paths and everything is just automated, it's not THAT hard, just annoying AF, so, instead of relying of root-only system-level libraries, binaries, etc., why not allow a user-first mode where a user-owned directory (under user home or maybe a new /userbin /userlib etc). Basically like each user would have their own environment separate from the system and separate from other users. Root-installed binaries would operate independently and not be affected by user binaries/libraries.
<snip>

Has this already been done and I'm just unlucky?
It may be that I have misunderstood your post, but as far as I can interpret it, the functions and facilities you appear to wish for already exist.

The user in linux can enable a /home/<user>/bin directory that is able to run programs compiled somewhere in /home/<user>/ in a directory of the user's choosing.

For example, a user can download either a binary tarball of a program, such as a browser like firefox, palemoon, mullvad etc., make a directory for it in /home/<user>/ somewhere, and run it from there, or from a link set in /home/<user>/bin. If one is inclined to compile a program from source, then the same applies, with the additional work of compiling. The compiler and other necessary building tools would need to be installed in the system files, but the compiled version of the executable could be run entirely from the /home/<user>/ directory.

If you are proposing the idea that the whole toolchain of building programs also be included in a /home/<user>/ directory, it would simply be an unnecessary duplication.

Exceptions to the above scenario are the programs that need to be run as root which need to have privileged access to the system files.
 
Last edited:
Linux distros (most notably RHEL) become even more of a bother to use when companies are running EOL distros and everything is outdated.
Compiling from source is the only solution, which everyone always asks 'well why would you do that?'
Yes, it's annoying when you see other distro maintainers provide updated packages but maintainers of your distro considerably lag behind.

I'm using debian and this is the case here very much, packages don't get updated as often as in other distros.

Even though I'd prefer packages to be updated I'm not overly upset because there is valid reason for this and also other benefits significantly outweigh this cost.

Therefore it boils down to you and what you want from your distro, there are distros with frequent updates but there are also drawbacks, so you need to take all factors into account and make your choice, one to which you'll stick in the long run.

Compiling something only because it will make a package in your distro more recent makes no sense,
compiling makes sense only if your distro does not provide a program at all or if you need some feature that is present in the new version of a package.

Biggest problem with compiling programs is not only the hassle of compiling but also that you'd need to manage compiled programs on your own (updating, uninstalling etc.), your package manager is useless for this.

Which ever distro you choose (depending on all factors important) just accept the pace at which packages get updated, which ever pace is better than manual handling of software.
 
Hi,

for longtime support with uptodate software you can try the following setup.

  • Install rockylinux 9 as os this os is supported for many years (10)
  • Install your software as flatpak so you have uptodate software .
 
Linux distros (most notably RHEL) become even more of a bother to use when companies are running EOL distros and everything is outdated.

This is one of the many reasons you shouldn't be running an EOL distro. When a distro reaches EOL, that's the end of its life. It's right there in the name. That's when you should stop using it, at the latest.
 
I am moving this thread to General Linux Questions as it is not a support topic related to beginning with Linux..

@callmelou welcome to linux.org

Chris Turner
wizardfromoz
 
Linux distros (most notably RHEL) become even more of a bother to use when companies are running EOL distros and everything is outdated.
I would have security on my ars if we were running an end of life RHEL version which didn't have an ELS(Extended Life Support) license. So this is not a normal thing thing to do, you migrate to the next version of the distribution unless you are running some old backend system running a cobolt application.
 
Yes, it's annoying when you see other distro maintainers provide updated packages but maintainers of your distro considerably lag behind.

I'm using debian and this is the case here very much, packages don't get updated as often as in other distros.
Different distributions have different software philosophies, Debian is known for being stable and only using free and opensource packages. If you want newer packages don't use Debian, RHEL or an LTS distribution but use a rolling release or something that is not LTS or use Flatpaks, AppImages or Snaps for those applications.
 
use Flatpaks, AppImages or Snaps
I have only yesterday discovered about flatpaks and installed it.
my mind is so divided I guess because I don't like Apple's style of how programs are installed, but otherwise it's very useful.

Are there any significant differences between the 3?
 

Members online


Top