Future of per-package repos vs. monorepo for downstream forks? #9
philm
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hi!
I maintain GitHub forks of several Manjaro packages that I previously synced from
gitlab.manjaro.org. Examples include:nvidia-390xx-utilsiso-profilesmhwdbWith the migration to
code.manjaro.organd the newPKGBUILDsmonorepo (https://code.manjaro.org/packages/PKGBUILDs.git), I would like to know how to continue syncing my GitHub forks from upstream.Questions:
Is the monorepo structure permanent, or only for migration?
If permanent, what is the recommended workflow for downstream users who maintain GitHub forks of individual packages?
Should I fork the entire monorepo on GitHub and then use sparse checkout,
git subtree,git filter-repo, or another method to track only the packages I care about?Will per-package repositories be restored, or should downstream users adapt to the monorepo?
Is there any official guidance or tooling for downstream forks to sync with the new structure?
Any guidance would be appreciated.
O.o
__
One related security question:
manjaro-iso-actionI also noticed a related change in
manjaro-iso-actionduring this migration.Several files that were previously obtained from Git repositories are now fetched directly from mutable
raw/branch/main/...URLs usingsudo wget, for example:pacman.confmakepkg.confmanjaro.gpgmanjaro-trustedmanjaro-revokedpacman-mirrors.confmanjaro-release/lsb-releaseThese files are subsequently installed into system locations and, in the case of the keyring/configuration files, directly influence the trust and package-management environment used to build the ISO.
I understand that this may be part of the ongoing repository migration, so my question is:
Is this
wget-based source retrieval inmanjaro-iso-actionintended to be temporary, or is this the planned permanent approach?If it is intended to remain, are there plans to add immutable source references and/or independent cryptographic verification (for example, pinned Git commits, signed source, or SHA-256 verification) before these files are installed and used by the build?
In particular, I would be concerned about replacing versioned Git source with mutable
raw/branch/main/...endpoints without an equivalent provenance/integrity mechanism.I am not suggesting that HTTPS itself is insecure; rather, I am asking whether the loss of the Git commit-level source identity and the absence of an independent integrity check are intentional.
If this is only a temporary migration workaround, then that's completely understandable — I would just appreciate confirmation that the current
sudo wgetapproach is not intended to become the permanent supply-chain mechanism for the ISO build system.One practical suggestion in the meantime
Just so you are aware: I still have synced GitHub forks of the repositories that were originally used as sources from GitLab.
These forks currently reflect the same upstream state as the corresponding GitLab repositories did, so if the new code.manjaro.org structure is only a temporary migration step, you could temporarily point manjaro-iso-action back to my GitHub forks for these repositories instead of switching to mutable raw/branch/main/... downloads.
That would preserve the previous Git-based source retrieval workflow while the long-term repository structure and synchronization method are being worked out.
https://github.com/megvadulthangya/pacman
https://github.com/megvadulthangya/pacman-mirrors
etc..
Update / follow-up question:
Since my original post, I'd like to ask specifically about the contribution workflow:
Now that code.manjaro.org uses a monorepo, how should external contributors submit changes? Is the old "import to GitHub, link branch in issue" workflow still valid, or is there a new preferred method?
Is forking enabled on code.manjaro.org, or is direct PR/MR submission possible there?
If neither is available, what is the recommended way to share a patch? (git request-pull, patch via email, etc.)
I'm asking because I maintain GitHub forks with local modifications and would like to know how to contribute them upstream properly.