I've built a service and I'd like to distribute it via rpm and should work on different fedora releases. Since it is a service it should be integrated with the system so it is possible to do:
$ service myapp start
The problem is that fedora used upstart in releases 9 to 14 and systemd from 15 and up. I can do this for both systems, but I'm not sure how to package it correctly.
I think I have to build different rpms for the fedora releases. The only thing that differs is a few files to be copied to different locations.
How should I handle the differences? In the .spec-file or Makefile? Or should I use two different .spec-files?
Do it in the spec file. Use separate sources for the upstart and systemd scripts, and include the appropriate script based on the version of Fedora being built on. So, single spec file to handle both cases.
Related
I'm trying to initiate astro. When i don't choose a framework i get this error although i have git installed and fully working. Any help will be highly appreciated.
√ Which frameworks would you like to use? »
> Copying project files...
could not find commit hash for latest
This seems to be an issue with degit. Please check if you have 'git' installed on your system, and install it if you don't have (https://git-scm.com).
If you do have 'git' installed, please file a new issue here: https://github.com/withastro/astro/issues
It depends on your OS and environment.
For instance, withastro/astro issue 2144 reports the exact same error message, but on Windows, using Linux on WSL2 (Ubuntu 20.04.3 LTS).
Double-check your %PATH%/$PATH in your execution environment.
Update Oct. 2022, ten month later: withastro/astro issue 2144 is reported closed with the workaround by Matej Bunček:
As I was researching this seems to be a general issue with NPM for those who uses SSH.
There's an open issue here: npm/cli#2610 which is still far from being resolved and it's a huge thread.
Some folks might be interested in these workarounds to get it working.
git config --global url."https://github.com/".insteadOf git#github.com:
git config --global url."https://".insteadOf git://
Also I've tried yarn, npm and pnpm, all of them seems to have same problem so I believe it's core problem of node.
Also both npm 6 and 7 are not working.
Not a direct solution to your error message, but a general solution for those kinds of errors:
I would recommend doing the development inside docker containers, so called devcontainers.
Since you will develop in separate and isolated environments containing only the project's minimum dependencies and tools, it is a lot less likely to face OS specific issues in general.
Here are some resources to get started:
https://code.visualstudio.com/docs/remote/containers
https://microsoft.github.io/code-with-engineering-playbook/developer-experience/devcontainers/
https://github.com/microsoft/vscode-dev-containers
I'm new with Perl and stumbled on a doubled modules installation.
I made a fresh installation of Strawbery Perl on Windows 10. After that, I tried to update all modules at once by using a command proposed in this answer; :
cpan-outdated -p | cpanm
Unfortunately, it appeared that probably the updates were installed on another location:
whichpm -a Mojolicious
C:\Strawberry\perl\site\lib\Mojolicious.pm
C:\Strawberry\perl\vendor\lib\Mojolicious.pm
whichpm -v Mojolicious
whichpm: WARNING: DUPLICATE module files found for 'Mojolicious':
C:\Strawberry\perl\vendor\lib\Mojolicious.pm
Mojolicious 8.22 (non-core) C:\Strawberry\perl\site\lib\Mojolicious.pm
How to deal whit that case?
How to prevent such cases in further updates?
perl -wE "say for #INC"
C:/Strawberry/perl/site/lib/MSWin32-x64-multi-thread
C:/Strawberry/perl/site/lib
C:/Strawberry/perl/vendor/lib
C:/Strawberry/perl/lib
Everything is working as expected.
There are three sets of installation locations: core, vendor and site.
The vendor directories are usually used by the package managers of linux distros, but it appears that Strawberry Perl includes a number of non-core modules in its distribution (including Mojolicious) and it places these in the vendor directories. This is proper.[1]
The site directories are used for user-installed modules. So your upgraded Mojolicious was installed into the site directories. This is proper.
(More on the differences here.)
This is not a problem because the site directories are placed before the vendor directories in #INC, so the user-installed version of a module is found before the vendor-installed version.
Using the site directories would probably also have been fine since Strawberry Perl doesn't provide a way of managing the distributions it bundles. But using the vendor directories is sure to be safe.
I downloaded and untared package named gnome-system-tools-3.0.0. When typing the command ./configure I've got the following error massage:
configure: error: glib-compile-schemas not found.
I've tried to update glib. I have the file glib-compile-schemas in /usr/bin directory.
OS: Fedora 28
These tools were last updated in 2011. That is seven and a half years ago. In computer time, that's.... ancient. You would probably need corresponding versions of other parts of GNOME and of system libraries from that era to even get it to build, and even if you did that, the actual features for system management are unlikely to work.
Instead, I encourage you to look at Cockpit, a modern GUI systems management tool. See these instructions for installing and launching Cockpit on Fedora.
I'm trying to create packages for some robot controller code that will support different architectures, such as i386 and armhf (for Raspberry Pi). I don't know how Debian intends this to be done. Is there a way to create a single .deb package that contains both binaries? Or must I create a separate .deb package for each architecture, which I do know how to do?
In the latter case, if I give the two packages the same package name, I can't put them both in the same repository, but if they have different names, users will have to specify which package they want to install using apt-get. Is there a solution to this problem?
You need to have different binary packages for different architectures unless what you're packaging is interpreted and not compiled.
If the package you're making is compatible with all architectures, then the Architecture: field of your debian/control file must be any. This is telling you that the package can be built in any Debian supported architecture. Then you'll just compile it and cross-compile it to i386 and armhf.
About your second question, you can. In fact, this is how is done in the official Debian repositories. The binary packages have a suffix in the file name containing the architecture. See this example. When users install your package, they won't need to specify the architecture as it's automatically detected.
On my Fedora 19 system, yum update attempts to reinstall a large number packages I have previously removed. This should not happen, as the packages listed are not installed and should not be suggested by yum. How can I make yum work in the expected manner - with updates suggesting only upgrades to preinstalled packages.
Background: I have been trying out new DEs - installing and removing them as I go. Currently, I'm in a DE-less state, booting directly into a tty terminal. My system has no (or a few hidden) xfce or cinnamon packages to "upgrade", yet the package manager is suggesting 300 packages to install, totaling 600M of new install.
Terminal output gist:
https://gist.github.com/Redoubts/29400f0b98cd13120a6a#file-gistfile1-txt
Short answer - It's not possible to disallow installing any packages from the depenency chain. Either you install all of them or drop those who depends on unwanted packages.
In some cases, when the package from a dependency chain is required only during some specific stages of installation (say for execution of a pre- or post-install scripts), it's possible to remove thise package later, after the complete installation. But that's not what you want I suppose.