pacman repositories

[fungilife]

https://github.com/jhuntwork/merelinux/blob/master/packages/pacman/pacman.conf

Is it too early to redifine the two repositories we know about?
The db file for both (stable and testing) is main, so both can't coexist as two separate repositories.
Whether sticking to the name stable or following arch's core/extra/community or Obarun's example of obcore/obextra/obcommunity to separate from arch's, mercore/merextra/mercommunity :)

At this stage it is hard to go back and forth since what is in stable may not exist in testing, but what is in testing may be up a version or extra... like linux and linux-headers.

About a base metapkg
I'd like to see net-tools instead of the "modern" IBMish way but that is just me :)

Aslong as I don't see elogind and zstd here I am with you 100%

I am trying to make enough of a base here to start building myself and testing things. It seemed impossible in the previous stage, I wonder what was your base for building the first few pkgs, alpine, adelie, void-musl??

You have my appreciation ....

[jhuntwork]

I think now would be a great time to nail down what the repository structure and names should be. Whatever we choose should have a specific, well defined purpose that is clear to those using it.

I'm not super familiar with the way Arch handles development, but it seems like those repository names might serve a different purpose than what I had in mind for stable/testing?

stable/testing was intended to provide a way to test packages together before they were ready for generic consumption, as a sort of development and release path. My thought was that packages under development are released to the testing repository when first created, and evaluated on various systems tracking the testing repository for a defined period of time. Then when they've been shown to be mature enough and we've practiced safe upgrades, testing is fully synced to stable. So, from that perspective, stable and testing are not supposed to be used on the same system.

So based on how things are now, if you're trying to get set up for development and testing you should definitely use the testing repo, while keeping in mind that I'm updating stuff regularly there now, and you might hit some bugs. Which reminds me, I should add an issue about documenting how I develop locally.

Ah yes, I took a look at Arch's documentation and they do have testing classes of repositories as well. https://wiki.archlinux.org/index.php/official_repositories

Having said all of that, it would probably be a good idea to draft a document similar to Arch's after we've defined what they should be. Having something like core/community/extra is fine as long as there is a development and release path for those too and they have clear purposes. We can also always start simple and add repositories as we go and identify needs.

Aslong as I don't see elogind and zstd here I am with you 100%

Never systemd. I have no current plans to use zstd, but mind explaining your thoughts about it?

About a base metapkg
I'd like to see net-tools instead of the "modern" IBMish way but that is just me :)

I'm not sure I understand what you mean here. Mind clarifying?

[jhuntwork]

Forgot to answer this question:

I am trying to make enough of a base here to start building myself and testing things. It seemed impossible in the previous stage, I wonder what was your base for building the first few pkgs, alpine, adelie, void-musl??

I've bootstrapped mere from scratch (several times) using a very similar process to LFS

Once I had working toolchain packages, I created a docker container image (mere/dev), and then I use some simple scripts to run new containers each time I want to build a package. I've found docker to be a much easier way to keep a clean environment for building then continuously managing chroots.

Basically, as long as I have dockerd running (right now I'm using a mere system that is running the static dockerd binaries), I can run ./scripts/build.sh packages/[somepkg] and it will launch a container and build the package for me.

I'll add an issue to document this more fully. I think I also have some local updates to scripts/build.sh that should be published soon.

[lufv]

So pacman isn't going anywhere for now, right?

[jhuntwork]

So pacman isn't going anywhere for now, right?

No. Someday I may re-evaluate package managers, but I'll bring it up as a topic of discussion before making any changes.

[fungilife]

One of the prime reasons I am interested in this project is because it does have pacman and musl. I have tried many (except for rpm) and I find pacman the most complete, versatile, and flexible pkg manager.

[jhuntwork]

@fungilife mind drafting a repository layout that you feel would make sense? Either inline here or as a PR that adds a markdown file to a docs directory or something. Then we can discuss it, and once agreed, accept it as an initial documented standard to start from.

About a base metapkg
I'd like to see net-tools instead of the "modern" IBMish way but that is just me :)

Also, any suggestions you have here? I'm not sure I entirely understand what you're suggesting.

[jhuntwork]

I reviewed more closely the Arch Linux repository documentation. I believe I'm OK following their pattern. I especially like the rolling release idea, and if the naming is familiar to others that will probably make it easier to use here. I'm not sure about doing what Obarun did, I presume that was for allowing simultaneous install of Obarun packages with Arch packages? While there are a few use cases where that might be nice, I think that's one where a user would have to tread carefully. Using statically compiled mere tools on an Arch host should be fine, but going the other route could produce weird results.

So, at this point, my plan is to mirror the Arch naming scheme (and stop overloading repository names with package groups). The extra repo and how that is published and managed will take some thought, but that can be a different issue to tackle after this.

As for net-tools, I'll look into that as a separate issue. The tools shipping with busybox were preferred due to being lightweight and having the advantage of removing dependencies and number of packages in a base install, but I can appreciate having a preference for a different tool set.