-
Notifications
You must be signed in to change notification settings - Fork 13
Description
[ Hello 👋
This issue proposes an optional, external integration between
Penguins-Eggs and PkgForge, implemented as a small adapter repo.
No core Penguins-Eggs code would be modified unless explicitly agreed.
Summary
The idea is to allow Penguins-Eggs to consume PkgForge-built artifacts
as a package backend, alongside existing apt/apk/etc workflows.
Penguins-Eggs would remain fully independent and distro-focused;
PkgForge would simply act as an optional build + cache source.
What this enables
- Reproducible ISO builds
- Reduced reliance on host distro repos
- Cleaner Alpine / non-Debian workflows
- Artifact caching and reuse
- Experimental distro-agnostic Eggs images
What this does NOT do
- No repo merge
- No rewrite of Eggs internals
- No replacement of existing package managers
- No new mandatory dependency
Proposed approach
- External adapter repo (
pkgforge-eggs) - Optional
pkgforgebackend selected via CLI - Declarative manifest shared between projects
- Eggs remains authoritative over snapshot + ISO logic
Status
This is currently a design + PoC proposal.
Feedback on scope and boundaries is welcome before any implementation.
Thanks for your time, and happy to adapt this to Eggs’ preferred workflow. ]
ChatGPT Chat Link : [ https://chatgpt.com/share/6983fc51-dbfc-8012-9a6c-d861f2750639 ]
Initial Inquiry : [ Could you assist with integrating, wrapping, merging & collaboration between Penguins-Eggs & PkgForge, please & thanks in advance.
https://github.com/pieroproietti/penguins-eggs
https://github.com/pieroproietti/penguins-packs
https://github.com/pieroproietti/fresh-eggs
https://github.com/pieroproietti/penguins-eggs-ppa
https://github.com/pieroproietti/penguins-alpine
https://github.com/pieroproietti/penguins-bootloaders
https://github.com/pieroproietti/eggsmaker
https://github.com/pieroproietti/pengui
https://github.com/pieroproietti/basket
https://github.com/pieroproietti/easy-menu-system
https://github.com/pkgforge/soarpkgs
https://github.com/pkgforge/devscripts
https://github.com/pkgforge/pkgs.pkgforge.dev
https://github.com/pkgforge/bin
https://github.com/pkgforge/aeris
https://github.com/pkgforge/soar
https://github.com/pkgforge/nix-appimage
https://github.com/pkgforge/sbuilder-go
https://github.com/pkgforge/sbuilder
https://github.com/pkgforge/squishy-rs
https://github.com/pkgforge/bincache
https://github.com/pkgforge/pkgcache
https://github.com/pkgforge/build-system
https://github.com/pkgforge/store.pkgforge.dev ]
Initial Response :
[ Oh this is a very good pairing. Penguins-Eggs and PkgForge actually complement each other almost suspiciously well 🐧🥚⚒️
I’ll break this down in a way that’s practical, realistic, and collaboration-friendly—not a big-bang merge that nobody wants to maintain.
Big picture: what this collaboration should be
Penguins-Eggs = system snapshot + live ISO + distro crafting
PkgForge = universal package production, caching, and distribution
Together, they can form a full lifecycle:
Build system → package artifacts → cache/store → OS snapshot → ISO/image → redistribution
Think of Eggs as “what the system becomes”
Think of PkgForge as “how software gets built, cached, and shipped”
- Conceptual integration map
Penguins-Eggs side (what Eggs already does well)
Component Role
penguins-eggs Snapshot → ISO
penguins-packs Package grouping
fresh-eggs Minimal base seeds
eggsmaker Build orchestration
penguins-alpine Non-Debian proof
basket Package sets
pengui UI frontend
bootloaders, easy-menu-system Boot UX
PkgForge side (what it adds)
Component Role
soar / soarpkgs Universal package format
sbuilder(-go) Reproducible builders
bincache / pkgcache Artifact caching
store.pkgforge.dev Distribution layer
nix-appimage Cross-distro app builds
squishy-rs Compression / FS tooling
aeris Infra glue
- Recommended integration strategy (no monorepo!)
❌ Don’t
Hard-merge repos
Rewrite Eggs around PkgForge
Force one build system onto the other
✅ Do
Layered integration
Optional backends
Shared schemas + conventions
Cross-project tooling
- Concrete integration points (the juicy part)
A. PkgForge as an optional package backend for Eggs
Add a new Eggs concept:
eggs package-backend:
- apt
- apk
- pacman
- pkgforge (NEW)
What this enables:
Eggs ISOs built entirely from pkgforge artifacts
Mixed sources (base OS + pkgforge apps)
Zero reliance on host distro repos
Implementation
Thin adapter in penguins-eggs
Calls:
pkgforge/bin
soar install
pkgcache pull
No deep coupling required.
B. Eggs → PkgForge build pipeline
Eggs already knows:
Exact package set
Versions
Architecture
Kernel + init + boot config
That’s gold.
New workflow
eggs produce manifest
↓
PkgForge sbuilder
↓
soar package set
↓
bincache/store
↓
Eggs ISO build
Artifacts become:
Reusable
Cacheable
Shareable across distros
This turns Eggs from “snapshot tool” into a reproducible OS factory.
C. penguins-packs ↔ soarpkgs
This is a near-perfect match.
Penguins-Packs PkgForge
Logical app groups Soar package collections
Role-based installs Declarative manifests
Desktop flavors App bundles
Action
Define a shared YAML/JSON schema
Auto-generate:
penguins-packs from soarpkgs
soarpkgs from penguins-packs
This avoids duplication and keeps both ecosystems in sync.
D. Eggs + squishy-rs + store.pkgforge.dev
Eggs outputs:
SquashFS
ISOs
Rootfs trees
PkgForge offers:
Optimized compression
Artifact storage
CDN distribution
Result
Eggs ISOs published via store.pkgforge.dev
Delta updates for Eggs remasters
Versioned OS images
That’s huge for bandwidth and CI.
- Alpine + non-Debian future
penguins-alpine + pkgforge/soar is where this gets spicy 🌶️
Alpine base
PkgForge apps
Eggs snapshot
Zero distro lock-in
You end up with:
A distro-agnostic OS builder
This positions Eggs way beyond Debian tooling.
- Collaboration model (this part matters)
Shared repos (new, small, neutral)
Suggested:
pkgforge-eggs-specs/
pkgforge-eggs-adapter/
eggs-pkgforge-manifests/
These should:
Be tiny
Be well-documented
Contain schemas + glue only
Maintainer boundaries
Eggs remains Eggs
PkgForge remains PkgForge
Integration lives between them
This avoids burnout and political friction.
- Suggested phased roadmap
Phase 1 (low risk, fast win)
Eggs → pkgforge binary cache
Manual integration
Proof-of-concept ISO
Phase 2
Package backend abstraction
Auto-generated manifests
CI builds using sbuilder-go
Phase 3
Store publishing
Delta ISOs
UI support in pengui
- What I can help you do next
If you want, I can:
Draft exact repo structure for the adapter
Write a PkgForge ↔ Eggs manifest spec
Sketch CLI commands (eggs pkgforge enable)
Prepare a maintainer-friendly pitch for both sides
Identify which repos should never be touched
Just tell me what you want to tackle first—and whether you want this framed as an experiment, addon, or long-term alliance.
This is one of the cleanest ecosystem fits I’ve seen in a while 👌 ]
