Create and build Debian/Ubuntu/Antix packages about glcapsviewer HOT 9 OPEN

AppImage (for amd64 and aarch64) would be way more useful and painless. The vulkan caps viewer works perfectly using AppImage. No dependency issue, and it just works.

from glcapsviewer.

Please provided at least some description.

from glcapsviewer.

1. currently the app scans own dir. In order to install it as a package, it should scan the dirs according to Filesystem Hierarchy Standard
2. menu entry is needed, so /usr/share/applications
3. package is needed. it is desireable to have it in official repos

from glcapsviewer.

I'm in the process of automating the AppImage builds for the Vulkan Caps Viewer. Up until now I had to manually build those, which was a tedious time-consuming process.

Once that works for the Vulkan Caps Viewer I'll try to do the same for the GL Caps Viewer.

from glcapsviewer.

@SaschaWillems On a topic of the AppImage, I have one small request. I think there is no need to wrap it in tar.xz. AppImage is already compressed (vulkancapsviewer 2.03 has AppImage 27.6MB, and tar.xz is 27.3MB, basically the same), and anybody downloading it know how to run it or set executable bit ;)

Thanks for you work on both gl and vulkan caps viewers and database. Super useful!

from glcapsviewer.

Oh. There is even an official guideline on this topic: https://docs.appimage.org/packaging-guide/distribution.html#do-not-put-appimages-into-other-archives

Also, you can use appimagetool --comp xz to use stronger squashfs compression if needed (probably already the default).

from glcapsviewer.

No dependency issue

@baryluk, appimage and all other "self-sufficient" stuff claiming "no dependency issue" are just lying. You cannot not to give a ... attention to dependencies (mostly they can be just updated without any harm and the apps will use the updated version and the user will have only the benefit, it is the way this dynamic library system is meant to work and it really works this way most of the time, but sometimes breaking changes are done, and it's your responsibility to fix your app) without severe issues including security ones. Dependencies are constantly updated and you app must support the latest version. If your app doesn't, it is unmaintained. If one stills considers this as maintainment, he is either doing self-deception or trying to fool someone else. So all this "self-sufficient containers" stuff is just crap for lazy people who don't want to do own work and prefer either someone else doing their work or just being harmed. It's better to have no packages at all rather than a "self-sufficient container" instead of them.

from glcapsviewer.

@KOLANICH I am perfectly aware that things like libssl will remain outdated in the built AppImage. It does however solve a major headache of dependencies. I didn't say AppImage is ideal, and solves everything, but it does in fact make things just work. The AppImage app will still use X11, OpenGL libraries, but they have very stable ABI and protocols.

You are free to download the sources of gl and vulkan caps viewers, and compile it yourself or package. Or package for a Distro, which will probably happen if Sascha abandons the project, but people find it useful, even without the data base support. But having package for unmaintained project is silly. It will break, and actually have more security issues. And if Debian package is provided instead, it will break too in the future, as library packages from Debian are constantly removed from Debian, like older libssl, older libstdc++, python2, etc, etc. Using a Debian package will not solve any of this.

Or run it in a container of some sort. Which you should do anyway for a binary from who knows where.

I would instead complain to libs that are designed in crappy way, openssl, that had many breaking ABI and API changes.

from glcapsviewer.

You are free to download the sources of gl and vulkan caps viewers, and compile it yourself or package.

I can do it for this app and I currently have to do it. But it is not the way the system should work. I can do it, but someone else cannot. Author has to build the stuff anyway while developing, so it's better to just publish what he has built. But not a self-sufficient container, only the app.

Or run it in a container of some sort. Which you should do anyway for a binary from who knows where.

1. Untrusted binaries shouldn't be run at all. Turing-complete code cannot be sandboxed reliably IRL. In an ideal world there are no vulnrs, so it can be sandboxed. But IRL there are vulnrs, and even if we know all the vulnrs present, answering the question "is this program trying to exploit any known vulnr" is undecideable.
2. But we still have to run binaries, and they can become untrusted. So we do defence in depth sandboxing them. But sandboxes for security and "self-sufficient containers" are different things having different goals. Security sandboxes have a goal not to allow an adversary to get access to sensitive data or resources. Self-sufficient containers have a goal "I wanna run different distros with different software on multiple machines and I wanna make starting a container fast, so I can scale automatically depending on load". Using self-sufficient containers for software distribution to end users is misuse of the technology.

from glcapsviewer.