Comments (7)
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?
from merelinux.
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.
from merelinux.
So pacman isn't going anywhere for now, right?
from merelinux.
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.
from merelinux.
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.
from merelinux.
@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.
from merelinux.
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.
from merelinux.
Related Issues (20)
- Determine initial config of kernel modules HOT 1
- Document development environment and workflow HOT 3
- Investigate nsss HOT 1
- Boot manager/loader HOT 1
- Before promoting testing, practice upgrading a current stable system using testing HOT 1
- Add installation instructions HOT 3
- python-dev conflicts with python
- Formalize a release strategy HOT 6
- Create a wiki HOT 5
- git does not include the Perl git module
- arm support, possibly aarch64 and armv7
- Package Manager
- Pacman should depend on ca-certs
- Some sort of alternatives support
- Separating packages from kernels, etc. HOT 5
- Detect version mismatch on provides
- Questions about usability HOT 2
- CI/CD improvements HOT 2
- Add zig package
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from merelinux.