linexer2016 wrote: Thu Feb 10, 2022 1:06 am
Thanks SR for clarifying that for me.
As far as the "bemusement" perhaps I should have used a slightly different word - maybe "confused"?
I was just playing around because you used such a awesome word.
linexer2016 wrote: Thu Feb 10, 2022 1:06 am
...
"There is a reason ulauncher wasn't packaged yet for MX-21, what that is I can't remember..." My concern was (and remains) that if a package had got a run at some point and was no longer available then the implication was there may be something wrong with said package.
There can be a lot of reasons why we don't/can't actually build proper Debian packages the correct way for our repos. That doesn't always mean there is something wrong with the package/application itself. If a application builds/compiles locally or some other automation system/workflow like what is used on GitHub, but it can't be built in a sbuild or pbuilder schroot, then we can't add it to the actual repos. Here is an example of a application that is probably a great application, but right now we can't add it to our repos because we can't cleanly build it in a proper schroot.
viewtopic.php?p=672983#p672983
I would say the one biggest things that stop us from getting a lot of packages into our repos sometimes is simply time and energy to work through all the nuances of getting a properly built package.
Its not that we couldn't work with the application developers to ensure their application build cleanly/properly, or do a bunch of work on the packaging to get the package to build properly, its that each such application takes time and energy to do that.
At the Debian level each package or set of packages could have one or many voluntary Package Maintainers dedicated to it. They can often focus and be more proactive than we can be, 500 maintainers can maintain 500 packages better than 4 maintainers can. Also, each package is different and can take extra effort because of different programing languages, different build systems, how the application functions/what it does, etc, etc.
But this makes sense, they are our parent Distro with massive structure, scope, and resources. Like all child/derivative Distros, we rely on the awesome work of the folks at the Debian level, their work and effort cannot be dismissed.
Here is a list of Packaging Teams for Debian
https://wiki.debian.org/Teams#Packaging_teams
This is an interesting list of packages that need a maintainer at the Debian
https://www.debian.org/devel/wnpp/work_needing
linexer2016 wrote: Thu Feb 10, 2022 1:06 am
... For my part, I will resist installing the application from Github until and unless it one day finds its way into the official repos. Again, this is not a package request :)
There is nothing wrong with using a .deb package provided by the
actual developer of an application. The catch here outside of being an official package from the developer is that it may not be compatible for whatever reason or hasn't been tested for stability and function with whatever version of Debian/MX you are using. The recommendation should be to play it safe, maybe try it in a VM first or at least use Timeshift and or have backups because you never know.
I can look at ulauncher again at some point, I wanted to package it, and at least attempted to at some point.
But right now I unfortunately got higher priorities in real life and for MX....