Source vs binary-based

[lufv]

Hello there!

I've been lately hoping through some distros (namely Gentoo, Void and Alpine) and what have caught my thoughts was how different package managers serve different purposes in a given distro.

Gentoo's Portage seems really big and complicated with all these options but because it is source-based distro where general user demands such amount of control over their system, this is what they ended up with. Probably the greatest feature of Portage or similar managers is USE flags and especially global USE flags that let user specify exactly what they want in their system from the very beginning and thus making it tailored to their needs.

On the other hand, managers in Void and Alpine are nowhere this complicated as they have nothing to configuration of the system or the software itself. They are just there to keep track of packages, files, updates and so on. Void's xbps doesn't even have build system itself - they provide additional scripts that create binary package which is installed as regular one. I belive this is the case with Alpine's apk and pacman as well.

So now I wonder what Mere is aiming for. Choosing pacman from the very beginning makes me think it is binary-based distro but ideas behind project seem like it's steering more into source-based teritory where simplicity is main goal. Every person uses something different and when simplicity means just essential software without unneeded dependencies we end up with millions possible setup. This is not possible to maintain such variety of options even for big distros, let alone for small projects. On the other hand, if we suppose that Mere is only server-oriented, source-based distro doesn't really make sense where, apart from really small projects, one could just not care about exact compile options and dependencies, especially when CLI tools are generally more lightweight. In the end, it is just smaller overall and that's what really matters.

Now, I'm sure Mere isn't going to give up on either of these use cases. I think that the main "selling points" of Mere are clang/llvm, musl, s6, pacman or general lightweightness. But if we account for simplicity it also seems more source-based-distro-like approach could be benefitial for an idea as well. I think this leads somewhere into comboing this two things into one environment, like two flavours - giving an user a choice whether they want to go source or binary-based. This could be either done by having two package managers to choose or more advanced scripts for pacman that could add USE flags for more control over software compiling.

I know this might feel like it's not that important to discuss but I've felt like this what I was kind of lacking about this project that could make it into a baseline on which one could build a system any way they want. I'm sorry this have turned into somewhat lenghty read but I just wanted to give some of my thoughts about this. Thanks for reading!

[jhuntwork]

@lufv thanks for the thoughtful input!

I've been thinking this over the past few days, but haven't had the time to really sit down and write a worthwhile reply. I will try to do that soon, but just wanted to drop a line to say I appreciated the message and am definitely thinking it over.

[jhuntwork]

OK, so finally have some time to write a meaningful reply.

I'm not entirely sure that simplicity equates to source-based. And, honestly, as a concept it could be interpreted to mean a number of things. When I say "Simplicity" is a goal, what I mean is that Mere shouldn't be a system that tries to fill every need. The base software shouldn't prioritize features over stability. Most importantly, I'd like for Mere to be easy to use and understand, avoiding unnecessary complexity wherever possible.

But if you are already picking up a 'source-based' feel about Mere, that's probably understandable. I have a personal history with the Linux From Scratch project, and Mere's history is really just me starting from a LFS-style toolchain and build system and figuring out how to carve out a small musl-based OS one piece at a time.

Having said all that, I think your idea may have some merit. Honestly, what you're describing sounds a bit to me like Homebrew. There's a lot of concepts about Homebrew that I actually really like, although I rather dislike that it's written in Ruby. (Ruby and PHP are both languages low on my list of priorities for supporting on Mere.) Some of Homebrew's concepts are what I was beginning to explore when I started writing my own package manager, here: https://github.com/jhuntwork/mere

Some of the concepts I was looking at were:

• Mix of source and binary-only packages
• Its own installation path, that could support both exporting to the main system (perhaps via symlinks) or running alongside another LInux OS in that dedicated path. That would allow, for example, running Mere's s6 as a supervisor on a Ubuntu machine.

I agree that Mere's biggest current strengths are clang/llvm, s6 and musl. And being lightweight. I think it makes sense to continue to make those the main focus and selling point. I think what's needed now is to make the system actually installable and usable, while fostering an openness and environment that others can contribute to so that it can grow. My thought was that putting the package management questions to the side for the moment would help that happen. However, I'm open to input and suggestions.

[lufv]

Hi, thank you for your response! I don't have really any experience with Homebrew to be honest, but I like what you wrote about it and I think it's great someone already wrote package manager around these concepts and it seems to work just fine. Also it's great that you're already working on one inspired by Homebrew (and others) as it seems to suit Mere well. Of course I agree and understand that there are few things more important at the moment, I just wanted to share some of my thoughts and I'm glad you like some of them. Thanks once again

[fungilife]

Is it possible in github to allow users to open a discussion by each pkg?
Reason I ask is I found a conflict between python and python-dev
/usr/include/python3.9/pyconfig.h exists in both 'python' and 'python-dev'

Xbps is not really that much simpler than pacman, I just have a preference to pacman due to more experience.
Still I wish I had made a ....stone .. to convert pacman to xbps and back for every flag and option.
I dislike the fact that xbps is split in many binaries each having different options/flags but it is not very intutive what operation belongs to which specific xbps tool. But there is xbps-src which is similar to makepkg and builds void pkgs from a template which is similar but simpler than pacman's.

The problem with xbps as it stands is that Juan ... who started void and wrote xbps has finally departed void after a 2 yyear agony and saga surrounding his existence. He was thrown out as being dangerous to the project. In retaliation he wanted to drag xbps out of void, but you can't do this with open/free software. So he started his own fork of his own software, and changed the license to I believe a BSD-3, which is nearly being non-free. Yet, a week after his departure and since the last time I looked, he hasn't added a single # to the code from what he forked.

So all void can do now is minor pkg alterations and patches to a piece of sw that is dead. Whether they are working on an alternative pkg manager to replace xbps I have no idea and I don't think this would be public knowledge.

Adelie's apk is not exactly the same or a fork of alpine's, the two share a name but have several differences.
Comparing apk to pacman or xbps is like comparing a skateboard to a SuperCar racer.

The fact that pacman works on musl is big news, especially this latest version that seems to have gotten pretty chunky. So I applaud you for your work.

Apart for making a shell alias for "sudo pacman" = pkg I wouldn't change a thing. And that together with musl has been the selling point. Adding s6 and 66 which is written in clean C has proven easy for any system, the exception was 32bit antiX which seemed to dislike some library location. They have worked for 2 years now in void 64/32 and architectures supported, glibc or musl.

[jhuntwork]

Is it possible in github to allow users to open a discussion by each pkg?

I believe you can, yes. You should be able to open either an issue or a discussion.

Reason I ask is I found a conflict between python and python-dev
/usr/include/python3.9/pyconfig.h exists in both 'python' and 'python-dev'

Yeah, sorry, haven't fixed that one yet, but I made an issue for it the other day: #376

...
The fact that pacman works on musl is big news, especially this latest version that seems to have gotten pretty chunky. So I applaud you for your work.

Apart for making a shell alias for "sudo pacman" = pkg I wouldn't change a thing. And that together with musl has been the selling point. Adding s6 and 66 which is written in clean C has proven easy for any system, the exception was 32bit antiX which seemed to dislike some library location. They have worked for 2 years now in void 64/32 and architectures supported, glibc or musl.

Interesting, thanks for the background.

Glad you're enjoying it so far, keep the feedback coming, please it's very helpful.

[fungilife]

For source based pkg management there is also an array of AUR "helpers" and the AUR like repository of locating source pkgbuilds. Years ago yaourt and a yaourt-cli was what thousands used, now they condemned it due to security issues that stem around the use of systemd's logind. So now there is the ultra-heavy yay. One tool I really liked for searching through the endless arch/aur repositories is package-query which I have forked just in fear of losing it. Browsing though void's repositories with xbps-query is really an exercise in patience and incorporates having to write pipeline scripts to get a valuable response.

Other than kernels, browsers, there are some horrible big cpu gazzling pkgs that will drive users away after having to build a couple of upgrades. So thumbs up on a combination system.

[ThisNekoGuy]

I can't personally make a jump to this distro due to my dependency on Nvidia's drivers but I would if that wasn't the case;
having access to the AUR is a pretty big selling point for me, personally, and I'd make that jump from Arch almost immediately if I was able to.

[jhuntwork]

Thanks for this feedback. I admit I previously dismissed the idea of testing AUR, because I suspected there would be some significant compatibility issues. But maybe it's not as bad as I imagine. It is probably worth looking into a little bit.