ani-cli
ani-cli copied to clipboard
Moar packages
Is your feature request related to a problem? Please describe. I want to get into application packaging, that's all.
Describe the solution you'd like Since my system has flatpaks and debs the options I feel motivation towars are a ppa and a flathub user repo.
Describe alternatives you've considered SNAPs are not ideal for scripts (I'm not even sure if containerizing would even work for ani-cli) and I have no experience nor knowledge with rpm packages.
Additional context
We already have a brew tap, a scoop bucket and an AUR package. Also having a flatpak (that depends on flatpak mpv) might be the solution for flatpak mpv support
If someone can package an apk for fdroid or research how you get into termux repos that would be great
Termux has its own package management and as far as I can tell it's a modified apt. I think we cna do that too. I don't think we should start to distribute termux apks, it will be hard enough to package our code
Also I looked into the fedora user repository, and copr looks quite a promising platform
Also I looked into the fedora user repository, and copr looks quite a promising platform
maybe we can even get into their regular repos, they seem a lot less strict than debian
https://repology.org/project/ani-cli/versions
I think we might already be in the termux repos 👀
/tenor pog frog
Nix package: #707
Why do we depend on ncurses-tools for termux? Works without it (the menu at least) I opened a PR downstream to fix some weird dependencies https://github.com/termux/termux-packages/pull/10485
As much as I would like to publish a package compatible package for all the distros via flatpak, it turns out since it's sandboxed we can't just run other applications (ffmpeg, aria2, mpv, vlc, ect...), not even their flatpak versions. Should I try my luck with regular packaging tools (debs and maybe rpms) or should I keep flatpak as a priority?
Try some regular packages. Looks like flatpaks isolation doesn't go well with a package that likes to interact with its platform
Just out of curiosity are you planing to build a package for debian that is simple and dose its job or are you doing it like the debian doc (https://www.debian.org/doc/manuals/maint-guide/start.en.html) say's it has to be done? @Derisis13
Just out of curiosity are you planing to build a package for debian that is simple and dose its job or are you doing it like the debian doc (https://www.debian.org/doc/manuals/maint-guide/start.en.html) say's it has to be done? @Derisis13
Thanks for presenting this resource, I have found a different documentation, but this one seems to apply more to us. I plan to keep conventions as long as it doesn't require changing anything (major) in the project. Also if you have experience in debian packageing you're more than welcome to maintain our debian package (which is yet to be made).
Just out of curiosity are you planing to build a package for debian that is simple and dose its job or are you doing it like the debian doc (https://www.debian.org/doc/manuals/maint-guide/start.en.html) say's it has to be done? @Derisis13
Thanks for presenting this resource, I have found a different documentation, but this one seems to apply more to us. I plan to keep conventions as long as it doesn't require changing anything (major) in the project. Also if you have experience in debian packageing you're more than welcome to maintain our debian package (which is yet to be made).
I have not much experience with debian packaging. But played around with it a little and got a package that works but i am not sure when it comes to some files (like copyright and the build in source control) so it will be by no means perfect. If you want to have a look at it https://github.com/Wiener234/ani-cli/tree/build-deb feel free to.
I have not much experience with debian packaging. But played around with it a little and got a package that works but i am not sure when it comes to some files (like copyright and the build in source control) so it will be by no means perfect. If you want to have a look at it https://github.com/Wiener234/ani-cli/tree/master/builds/deb feel free to.
I checked your repo, and it seems promising and I'd prefer to work on that instead of creating an own package. I'm still thinking how it would best be executed and there are changes I'd like to see.
I'm still inexperienced with Github and how that works so do what you think is right with the repo. If you need something just say so.
We should focus on the important package formats first
- [x] .deb (Debian) as ppa or in a repo
- [x] .rpm (Fedora) in copr
And later, or if a user on such a distro exists, support more niche distros
- [ ] xbps (Void) package
- [ ] apk (Alpine) package
- [ ] eopkg (Solus) package
Is there a real value behind getting the .deb package into a ppa?
I mean that the only thing that needs to be updated is the ani-cli script and that is already build into it (ani-cli -U
).
While the point of easy install with a ppa is not realy given 'cause you need to find the link for the ppa and add the ppa. You can also just download the .deb and install it with apt install /location/to/.deb
.
Is there a real value behind getting the .deb package into a ppa? I mean that the only thing that needs to be updated is the ani-cli script and that is already build into it (
ani-cli -U
).While the point of easy install with a ppa is not realy given 'cause you need to find the link for the ppa and add the ppa. You can also just download the .deb and install it with
apt install /location/to/.deb
.
I mean we need the .deb first anyway. After that our own repo / ppa would be an optional intermediate step before we get into downstream repos
Could someone check over the content of the copyright file to make sure there is no mistake. https://github.com/Wiener234/ani-cli/blob/build-deb/debian/copyright
If there are non then the Debian package would be ready and i would go ahead and create a ppa for it and see how to get it into the Debian repo.
I'll check it, but I want to do it more thoroughly, so it'll take some time.
Extension: Ubports support
Experimental .rpm packages are available from https://copr.fedorainfracloud.org/coprs/derisis13/ani-cli/
Short update on the .deb package. I'm looking for a sponsor right now. If i found one the package should land in the official repo.
Short update on the .deb package. I'm looking for a sponsor right now. If i found one the package should land in the official repo.
Wow, nice! What kind of sponsor are you looking for and why is it a prequisite for having a package in the official repo?
Wow, nice! What kind of sponsor are you looking for and why is it a prequisite for having a package in the official repo?
A sponsor is someone who has the rights to upload a package to the official repo when the person packaging doesn't have it.
Regarding the ani-cli package in the offical repos, someone else is also working on that and i will leave it up to that person. https://mentors.debian.net/package/ani-cli/
I will continue to maintain the PPA until the package gets accepted into the offical repos.
Also having a flatpak (that depends on flatpak mpv) might be the solution for flatpak mpv support
It would be fantastic to have a flatpak with all optional dependencies for ani-cli such as VLC installed alongside for the same feature list as the current non containerized version.
Unfortunately the sandbox nature of flatpaks makes it difficult to package ani-cli without modification. I want to give it another shot, however it'll take me some research and even then I don't know if its possible.
Official debian package is live