caprine
caprine copied to clipboard
sindresorhus
Linux packages and distribution
This issue was opened as a place to discuss Linux packages and their distribution since it was brought up recently (https://github.com/sindresorhus/caprine/issues/1848#issuecomment-1205806923) and I mentioned again publishing packages to official distribution repos (https://github.com/sindresorhus/caprine/issues/1458).
@lefterisgar to respond to your comment in a different issue (here it's more on topic) https://github.com/sindresorhus/caprine/issues/1848#issuecomment-1206196743
Especially when Caprine is already included in the deb-get index where releases from GitHub are automatically distributed without any effort at all.
I was not aware of that! That sounds great. Last time I used Ubuntu as a daily driver, I had to download deb files and install them manually in order to get updates. Are updates now downloaded automatically via the package manager from GitHub? If that is the case, that option is imho much better than maintaining a ppa.
Isn't the majority of Linux users using Debian?
That is, as everything with Linux, up for debate 😁. Right now the most popular distros are from what I can see Ubuntu based ones (Ubuntu, Linux Mint, PopOS... however they do diverge a fair amount), Manjaro (there is a package in Arch repos and thus in Manjaro repos so we're fine on that front) and Fedora (it's been gaining more and more traction in last few releases, mostly new users or old Arch/Ubuntu users but I might be mistaken). In that sense, in order to cover most if not all of the Linux userbase, there should be a deb package, a rpm package and an Arch package. Since electron is fairly compatible and distro independent (however there were some issues with dependencies on Debian iirc), there could potentially be one deb, one rpm package.
I already maintain rpm packages in my copr repo (for Fedora, EL and OpenSuse) so deb packages are the thing that's left. PPAs are from what I know Ubuntu focused and might bring some issues on other deb based distros so that we should be careful about.
Yes, we could give it a shot and just see how it goes. Maybe automating the entire process would help.
Automation would be ideal, however I don't think it should be included into this repo... yet. Rpm packages I make are not yet included however the process of publishing is fairly automated thanks to copr. If ppa will be added as a way of distributing Caprine, I think there should be a very good reason to do so instead of "let's just do it". Maintaining ci/cd pipelines is already a significant task so I'd rather be completely sure we want that before committing to it.
I was not aware of that! That sounds great. Last time I used Ubuntu as a daily driver, I had to download deb files and install them manually in order to get updates. Are updates now downloaded automatically via the package manager from GitHub? If that is the case, that option is imho much better than maintaining a ppa.
No, simply installing a deb file doesn't mean you will also get updates. A small number of them (very popular apps like Google Chrome) include a script that adds an APT repository when the application is run for the first time. APT only downloads packages stored on APT repos. Deb-get is 3rd party software that makes it easier to install and update apps that don't have an APT repo (such as Bitwarden or Caprine). It supports direct downloads from an app's website or even GitHub releases.
That is, as everything with Linux, up for debate grin. Right now the most popular distros are from what I can see Ubuntu based ones (Ubuntu, Linux Mint, PopOS... however they do diverge a fair amount), Manjaro (there is a package in Arch repos and thus in Manjaro repos so we're fine on that front) and Fedora (it's been gaining more and more traction in last few releases, mostly new users or old Arch/Ubuntu users but I might be mistaken). In that sense, in order to cover most if not all of the Linux userbase, there should be a deb package, a rpm package and an Arch package. Since electron is fairly compatible and distro independent (however there were some issues with dependencies on Debian iirc), there could potentially be one deb, one rpm package.
~~I have now added rpm in the Linux targets so the next release should have an rpm package. 😀~~
From GitHub's API: Caprine 2.55.6 Downloads: caprine_2.55.6_amd64.deb 1496 Caprine-2.55.6.AppImage 872 caprine_2.55.6_amd64.snap 103
So it looks like at the moment, Debian is the most popular distro among Caprine users.
If ppa will be added as a way of distributing Caprine, I think there should be a very good reason to do so instead of "let's just do it". Maintaining ci/cd pipelines is already a significant task so I'd rather be completely sure we want that before committing to it.
I 100% agree with you. Don't know if it's worth it but consider that a big number of users don't update Caprine due to that. Maybe we can leave this discussion open and decide about that in the future.
I have now added rpm in the Linux targets so the next release should have an rpm package.
I'm sorry, I have dropped the commit and rebased.
A small number of them (very popular apps like Google Chrome) include a script that adds an APT repository when the application is run for the first time. APT only downloads packages stored on APT repos. Deb-get is 3rd party software that makes it easier to install and update apps that don't have an APT repo (such as Bitwarden or Caprine).
Yeah, I thought Caprine somehow also adds a repo, at least that what I (wrongly) understood 😅. Now that you've refreshed my memory, I know about deb-get. It's nice to know that Caprine is distributed that way. Just a thought, we could rewrite the Linux packages section in readme so it has more information on all packages and ways to install them. But if we do that, there should be a clear distinction between official packages and distro released ones (snap, deb, appimage, macOS and Windows which are released in this repo and Arch Linux which is maintained by Arch package maintainers) and third party and distro packages and sources (rpm for Fedora, RHEL and OpenSuse, flatpak and in this case deb-get). I'd put deb-get in the unofficial list since the deb-get tool itself is unofficial and not really adopted by many distros. I'm however open for discussion about this. The goal of this would be just avoiding responsibility of potential issues with deb-get.
So it looks like at the moment, Debian is the most popular distro among Caprine users.
It definitely is one of the popular ones 😁. We don't have any stats for the Arch repos from what I know but the rpm repo on COPR is used by 700 devices in total while there is usually more than 1k app updates on release via flathub. Anyway as I've said, I'm not against ppa, I'd just like to be careful about it since while releasing rpm and flatpak packages I had regular trouble in the beginning and I'd rather not make it an official source for Caprine for now. Anyone is free to automate the process of releasing the package on ppa but for example rpm spec and flathub manifest are not yet added to this repo. Also, keep in mind that creating a ppa would require building the Caprine deb package from source (or use already built binaries but it adds up to the same thing since you'd need to make your own package instead of using the one build by electron-builder).
Don't know if it's worth it but consider that a big number of users don't update Caprine due to that.
Considering the numbers, it would probably be worth it but it also takes time 😁. We'll leave this open and use it as a place for discussing these things.
To summarize for now. I'd rather have rpm and flatpak packages stay unofficial for now (alongside deb-get) and anyone interested in making a ppa for Ubuntu users is free to do so but it will probably also be unofficial in the beginning. In the long run, Caprine packages should be added to official distro repos so we won't have to worry about anything regarding this 😁, ideally only snap, flatpak and appimage packages would be maintained by us at that point (since that's the idea of those package formats, to be maintained by program authors).
One thing I'd just like to add that could be useful for distro package maintainers (for example Arch or any other unofficial package maintainers). Alongside release notes for regular users there should be a section for package maintainers which contains some information that might be of use for them like a change in Electron version, updated dependencies, changes in config directories or any kind of fs structure... That way we can ensure that even packages we do not maintain can get the best possible care.
// @sindresorhus
Just a thought, we could rewrite the Linux packages section in readme so it has more information on all packages and ways to install them. But if we do that, there should be a clear distinction between official packages and distro released ones (snap, deb, appimage, macOS and Windows which are released in this repo and Arch Linux which is maintained by Arch package maintainers) and third party and distro packages and sources (rpm for Fedora, RHEL and OpenSuse, flatpak and in this case deb-get). I'd put deb-get in the unofficial list since the deb-get tool itself is unofficial and not really adopted by many distros. I'm however open for discussion about this. The goal of this would be just avoiding responsibility of potential issues with deb-get.
I just couldn't agree more with what you said. There needs to be something (like a table) that lists all third party sources/repos and who is responsible for maintaining them.
I wouldn't say that the deb-get release is unofficial, because the tool itself downloads Caprine from the official GitHub repo. You could say something like "If you want Caprine to stay up-to-date, install deb-get and it will download the latest release automatically."
It definitely is one of the popular ones grin. We don't have any stats for the Arch repos from what I know but the rpm repo on COPR is used by 700 devices in total while there is usually more than 1k app updates on release via flathub. Anyway as I've said, I'm not against ppa, I'd just like to be careful about it since while releasing rpm and flatpak packages I had regular trouble in the beginning and I'd rather not make it an official source for Caprine for now. Anyone is free to automate the process of releasing the package on ppa but for example rpm spec and flathub manifest are not yet added to this repo. Also, keep in mind that creating a ppa would require building the Caprine deb package from source (or use already built binaries but it adds up to the same thing since you'd need to make your own package instead of using the one build by electron-builder).
It seems like another repo is not worth the trouble. At least that's what I think. Maybe if people use deb-get it can be avoided. I'm saying that because deb-get will update more packages for them, other than Caprine.
One thing I'd just like to add that could be useful for distro package maintainers (for example Arch or any other unofficial package maintainers). Alongside release notes for regular users there should be a section for package maintainers which contains some information that might be of use for them like a change in Electron version, updated dependencies, changes in config directories or any kind of fs structure... That way we can ensure that even packages we do not maintain can get the best possible care.
Yeah, sure. But it's our responsibility to bump things like Electron. Having maintainers do this sort of thing is a nightmare because Electron has a lot of breaking changes between releases. Alternatively we could set something like Dependabot up.
You could say something like "If you want Caprine to stay up-to-date, install deb-get and it will download the latest release automatically."
I'd rather not give any personal opinions about repos and other sources for downloading and updating Caprine (i think this sentence could be interpreted as one). Especially because it could be understood that we're somehow endorsing use of that source specifically (I'm not saying that it's our intention or that it's bad to endorse apt-get or any other tool but it's just not what we should do). That way we could avoid any responsibility for those sources. Our sources and our responsibilities are packages built and distributed in this repo. It might be a bit radical thinking but it's just a way for us to avoid any unwanted issues and criticism, we already have enough work on our hands :).
Maybe if people use deb-get it can be avoided. I'm saying that because deb-get will update more packages for them, other than Caprine.
Fair enough. We could just list all repos and tools that support Caprine and split them into official (like I said, those from this repo) and unofficial (everything else). The only thing that could probably be considered "official" is official distro repos (for example Arch).
Yeah, sure. But it's our responsibility to bump things like Electron. Having maintainers do this sort of thing is a nightmare because Electron has a lot of breaking changes between releases. Alternatively we could set something like Dependabot up.
My rationale behind that was for distros that package Electron separately (like Arch) need to know which version of Electron is used for each release of the app. There was an issue when the Arch package used the latest version of Electron from Arch repos (at that time 14) and it broke the app since Caprine at that time still used remote api which was supported up until 13 so the package maintainer didn't know that they should switch to a different electron package. By publishing some useful information for package maintainers (such as versions of larger dependencies or some breaking changes) it could save us and them some trouble when publishing packages to repos that are not maintained by us (since we know that needs to be changed but they don't because they don't really follow discussions, only read release notes).
I'd rather not give any personal opinions about repos and other sources for downloading and updating Caprine (i think this sentence could be interpreted as one). Especially because it could be understood that we're somehow endorsing use of that source specifically (I'm not saying that it's our intention or that it's bad to endorse apt-get or any other tool but it's just not what we should do). That way we could avoid any responsibility for those sources. Our sources and our responsibilities are packages built and distributed in this repo. It might be a bit radical thinking but it's just a way for us to avoid any unwanted issues and criticism, we already have enough work on our hands :).
That's fine. It might be misinterpreted. However, we should emphasize on the fact that the deb-get "release" has no maintainer because itself is the official release. It doesn't matter if you download it from an web browser, from deb-get or even wget for that matter. The way I expressed it was definitely not the best.
It might be a bit radical thinking but it's just a way for us to avoid any unwanted issues and criticism, we already have enough work on our hands :).
Exactly!
My rationale behind that was for distros that package Electron separately (like Arch) need to know which version of Electron is used for each release of the app. There was an issue when the Arch package used the latest version of Electron from Arch repos (at that time 14) and it broke the app since Caprine at that time still used remote api which was supported up until 13 so the package maintainer didn't know that they should switch to a different electron package. By publishing some useful information for package maintainers (such as versions of larger dependencies or some breaking changes) it could save us and them some trouble when publishing packages to repos that are not maintained by us (since we know that needs to be changed but they don't because they don't really follow discussions, only read release notes).
Not only that but the release notes should be more detailed even for end-users. For example, they should know that by updating Electron in this release, Caprine runs perfectly on Wayland and Ubuntu 22.04 is finally supported.
In addition to deb-get, win-get and chocolatey could be added to the list since Caprine packages are available there too. They however need to be updated.
That's great! I just checked chocolatey and it seems like the maintainer is updating the release. Winget is a bit behind tho.
Right now I'm testing GitHub Actions + PackageCloud and it is able to successfully push packages which then users can upgrade to. Of course I'm only going to be publishing debs there.
You can add this as an APT repo via this command:
$ curl -s https://packagecloud.io/install/repositories/lefterisgar/caprine/script.deb.sh | sudo bash
I'm using the free version and with my calculations it should be able to handle about 160 users per month. Because Caprine is open source we could ask them for free hosting.
That's great! I just checked chocolatey and it seems like the maintainer is updating the release. Winget is a bit behind tho.
BTW, I am the maintainer of the Chocolatey package :grin:
My packaging script is automated to get the last release. I'm open to automating the process even more, if possible, since the script still needs to be manually triggered.
That's great! I just checked chocolatey and it seems like the maintainer is updating the release. Winget is a bit behind tho.
BTW, I am the maintainer of the Chocolatey package grin
My packaging script is automated to get the last release. I'm open to automating the process even more, if possible, since the script still needs to be manually triggered.
Perfect! I'm not sure if anything can done using GitHub actions, but if you decide to go that way it must be a fork because we don't have access to GH secrets for this repository.
I'm going to include a link to the Chocolatey package in the readme file now that I know who maintains it.
This is great news! From the discussion on the pr for updating the readme (https://github.com/sindresorhus/caprine/pull/1885#discussion_r950861492), it seems like that Lefteris will move deb repo from packagecloud to gemfury since there is no bandwith limit on gemfury afaik (they don't however have gpg checks but I'm not sure weather packagecloud has it either).
I'll work on polishing the flatpak manifest so it could be proposed to this repo as an official package (in order to publish flatpak packages on flathub the manifest needs to be in the flathub repo so we'll maintain it here and copy it to flathub repo). That means we won't use electron-builder for flatpak package unlike for other packages.
As for rpm package, I'd prefer to push that to Fedora repos so it gets published to official distro repos rather than our repos but it will take time.
Also, it would be great if we could publish all automation scripts for distributing packages on a public repo (not necessarily this one) so the distribution process could be more transparent and easy to find and understand. It's not really something that's required but it would be cool since Caprine is already open source.
From the discussion on the pr for updating the readme (https://github.com/sindresorhus/caprine/pull/1885#discussion_r950861492), it seems like that Lefteris will move deb repo from packagecloud to gemfury since there is no bandwith limit on gemfury afaik (they don't however have gpg checks but I'm not sure weather packagecloud has it either).
Packagecloud had gpg support (I discovered it by looking at the bash script). Gemfury is supposed to support it as well (their documentation has instructions on how to set it up) but I can't find any button or link in the dashboard related to it. But it doesn't matter anyways. The problem with Gemfury is that they don't provide a script for easy set-up like Packagecloud did (their script is 232 lines long!). That's why I have opened a new PR that adds a script that I wrote based on Gemfury's docs.
Also, it would be great if we could publish all automation scripts for distributing packages on a public repo (not necessarily this one) so the distribution process could be more transparent and easy to find and understand. It's not really something that's required but it would be cool since Caprine is already open source.
Yes, this should be prioritized because Caprine is open source and users must know where the binaries come from so they trust them. FYI all the distribution process for .deb packages is open for anyone to see in my fork (GH Actions).
Sorry, fokls, for jumping in out of the blue. I just saw the latest release and wanted to express my gratitude and appreciate the effort on adding update automation for deb-based distros by means of https://apt.fury.io/lefterisgar/ (I'm on Ubuntu and Mint on my two laptops). Thank you very much 🙇🏻 I'd prefer PPA instead of apt.fury.io, which I haven't heard of before, though it's a way better than watching for release announcements, download and manually install Caprine.
We're glad users are already noticing and it's helping them!
I'd prefer PPA instead of apt.fury.io
We already discussed PPAs (https://github.com/sindresorhus/caprine/issues/1868#issuecomment-1206224439) and I'd prefer we don't use them for two main reasons. One is that PPAs are more Ubuntu focused and it would be better that they are only used on Ubuntu in order to avoid any unwanted issues. That would in turn limit the number of deb based distros that could auto-update Caprine through the package manager. The second one is that PPAs require a specific distribution process, preparing sources and control files and building the package on Launchpad which would mean someone needs to learn and maintain that process. Right now in the gemfury repo there is a package that is automatically created by electron-builder which means for no no one needs to learn anything dramatically new and difficult so it makes our life as maintainers easier.