Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish packages to PackageCloud.io #34

Open
simoncaron opened this issue Jun 5, 2023 · 3 comments
Open

Publish packages to PackageCloud.io #34

simoncaron opened this issue Jun 5, 2023 · 3 comments
Labels
enhancement New feature or request

Comments

@simoncaron
Copy link
Contributor

Hey @wofferl ! Not really an issue but I noticed you created workflows to build packages using GH Actions, nice!

I was wondering if you considered publishing the packages to a cloud repo like packagecloud.io? It would simplify the update process when a new version is available. I started a few release back to upload mine manually to my packagecloud instance and configured it as a repo on my Pi ex:

[/etc/apt/sources.list.d/packagecloud_io_simoncaron_pbs_raspbian.list]
deb [signed-by=/etc/apt/trusted.gpg.d/simoncaron_pbs-archive-keyring.asc] https://packagecloud.io/simoncaron/pbs/raspbian bullseye main

There are some Github actions to publish packages on packagecloud.io (or another provider) and there is a free plan too.

Just a suggestion, again great work!

@wofferl
Copy link
Owner

wofferl commented Jul 21, 2023

I'm experimenting a bit with repositories right now.

But I'm not sure if I really want to do that. The step of releasing binary packages already brings more responsibility that the packages are correct.

With a repository, people quickly forget that these packages are not official and there is always a risk of something going wrong.

@wofferl wofferl added the enhancement New feature or request label Dec 1, 2023
@bert128
Copy link

bert128 commented May 1, 2024

I'd second this request, if only because it's inconvenient to manually pull down all the individual debs from github and copy them onto the machine every time there's an update.

In terms of responsibility, having it more difficult to update will just result in people not updating, potentially introducing different issues. It's pretty clear that this is an unofficial build and anyone using it has to accept responsibility themselves.
Repositories are signed with GPG keys too, whereas random deb downloads are not. This would actually provide an increased level of security. Of course anyone using it would have to choose to trust your GPG key, but this would give much greater assurance that someone else hasn't tampered with the packages.

Now if only the Proxmox team would officially endorse ARM, this is extremely useful to run a backup server on a low power ARM based NAS i have at home, accepting backups from colocated servers.

@stefansaraev
Copy link

imho "./build.sh download" is enough, and whoever wants to, can reprepro the downloaded debs to an internal repository. just my 2 cents, and thanks for the good work @wofferl

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants