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

Distribute prebuilt packages #233

Open
KOLANICH opened this issue Sep 19, 2019 · 5 comments
Open

Distribute prebuilt packages #233

KOLANICH opened this issue Sep 19, 2019 · 5 comments

Comments

@KOLANICH
Copy link

No description provided.

@sabel83
Copy link
Member

sabel83 commented Sep 21, 2019

Please be a bit more specific about the issue.

@KOLANICH
Copy link
Author

KOLANICH commented Sep 22, 2019

There are lot of distros. In distros there are package managers. Package managers use repos to get packages. There are usually 3 kinds of repos:

  • an official repo of a distro - usually ships obsolete packages considered time-proven
  • an repo by software developer - usually ships freshest releases and nightlies
  • a repo by 3rd party - usually ships packages if there is no official repo by a dev or if they contain patches not merged into upstream.

There are some well-known truths about package management:

  • All the software must be distributed in form of packages. Even if it isn't, a user has to use the tools like checkinstall to create a fake package. This simplifies installation, uninstallation, update and conflict detection.
  • dependencies should be separate packages and the app should not break when its dependencies are updated. And this is not impossible and even not as hard as people have recently become thinking. Self-sufficient containers as surrogate to package managers are just fashion.

So it'd be nice to have official packages for this tool and all its dependencies (the most importantly, templight, and it should use llvm libs from the packages, not own-built ones) for all major distros used on desktops (debian, ubuntu, antix, fedora, arch, suse). For llvm there is an official repo by its devs. They ship both llvm 9 and llvm 10 (nightlies), I have been using clang-10 nightlies exclusively for quite some time (and even have rebuild some packages to make them link llvm 10 instead of llvm 8 with very minor code changes and they work fine) and IMHO llvm 10 and clang 10 work well enough for daily use (there are some issues in packages, such as missing symlinks, but they are easily resolved by a user familiar to dpkg), so I guess the packages should not depend on an obsolete (non latest) versions of llvm, or if they have to, there should be separate packages allowing me to not bloat my system with different versions of llvm unneeded for me.

@sabel83
Copy link
Member

sabel83 commented Sep 25, 2019

So if I understand correctly, the actual issues are:

  1. No repository to periodically pull nightly builds from is available
  2. No Metashell packages without Templight are available

Is my understanding correct?

@KOLANICH
Copy link
Author

KOLANICH commented Sep 25, 2019

  1. Correct.

  2. We need the packages. I mean installation of metashell should be as simple as sudo apt install metashell. If there is no packages for templight, we have to create them too. Probably for templight we need a separate repo (it is not a problem since the code creating it can be reused).

  3. in the end the packages should go to distros official repos.

The main problem is to build everything using the libs from the packages (currently it looks like it is not possible to build templight using the libs from existing packages without modifying cmake scripts) and to create the packages (for example debian debhelper looks damn fragile (does something I haven't requested to do, writes errors that soke files have changed even though that these are bijary build files, cannot unpack tar.gz archives (asks for --zstd IDK why (the archive is really tar.gz, not tar.zst) ), cannot unpack uncompressed tarballs IDK why, gnu make and so bash-based, so no complex behavior without perversions like parsing CLI tools human-readable non-machine-readable output) so I had to get rid of it and replace it with own python scripts in my repos. Probably it is a more dirty approach not making use of debhelper machinery, but at least the build succeeds without strange error messages of unknown origin and I don't have to use bash and gnu make for the things they are not designed to be used).

@sabel83
Copy link
Member

sabel83 commented Sep 25, 2019

Note that for released versions there are packages you can download and install - see http://metashell.org/getting_metashell/installers/index.html

Building the code generates the packages (eg. .deb on Debian or Ubuntu, .rpm on Fedora or SuSE, etc). They contain both Templight and Metashell and there are no repositories for them.

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

No branches or pull requests

2 participants