For example I have Intellij Idea installed on my Arch Linux system. Intellij Idea has built in updater and assume that I's already updated Intellij Idea with that built in Intellij Idea updater. But when I perform "yaourt -Syu" corresponding Intellij Idea's package is still shown in list of packages that are waiting for updates. So how can I say yaourt or pacman (or any other pacman wrapper that may have such feature) that package is already updated?
If you just want that Feature I would recommend yay to you, it has that Feature to skip an installation of a Packet! As discussed here you shouldn't use yaourt anymore.
If you don't want that update Problem at all install jetbrains-toolbox which will manage your installed IDEs, if you are using more than one, so you only have to update the toolbox once in a while.
The problem is that you haven't updated it. You've overwritten the copy pacman knows about, with an untracked copy from elsewhere.
So, of course, pacman's metadata will not be updated. In order to circumvent this you'd need to create a custom dummy package which provides intellij, while managing it entirely yourself.
But what is wrong with using the official repository package https://www.archlinux.org/packages/?name=intellij-idea-community-edition and just letting pacman update it for you?
Related
I am working on a ROS package to be deployed on our lab robots. There is a feature in my package requires a third party ROS package. I don't think this package is released yet, at least I couldn't find it at ROS wiki document site. The dependent package is called ros_msg_parser for subscribing topics without knowing their msg type beforehand. Here is the link to the repo. (https://github.com/facontidavide/ros_msg_parser)
I need to mention that we use ubuntu 16.04 in all our devices. And we program with ROS, and C++.
My intention is to deploy my own ROS package to the robot without worrying about if the ros_msg_parser package is installed on the device or not.
I know a couple of ways to do it:
Use a .so library file. (We don't think this approach is the ideal way to proceed for us, since the .so library is going to be a black box for other colleagues in lab in future, and no way to know its version and so no.)
Release ros_msg_parser ROS repo and use it as a ros eco-environment program, such as std_msgs.
And at last, (not we want) we could build/install this ros_msg_parser package on all our devices.
I have also researched on externalpackage_add, to build/install ros_msg_parser as a third party library. Then I realized that I am using a ros package as my dependency, not really the standard way of build && cmake && install. Correct me if I am wrong.
I have desired package working alright now, by catkin_make the ros_msg_parser package in my working space together.
I am just wondering if any one can help me with things like if there is any approach I can do or any where I can research on my own to fulfill my goal.
Thanks in advance.
Furtunately, I have got some help from team to solve this problem. It is rather simpler than I imagined.
Here are the steps that we took to implementation:
git clone the ros pacakge source and only copy the source files to a folder called your_third_party_folder/ parallel to your_main_work_space/src folder. Remember to remove your git clone histories etc, you will only need the source files, otherwise your main work space won't work well with your own repo. Due to a dirty repo prompt, you will not be able to push our third_party project to your repo. Maybe there are another ways to solve this, but it is just simpler to copy the source files to a folder where want.
work on your two CMakeLists.txt files, make sure to inlcude, link and target some libraries to pass catkin_make
and don't forget to add_subdirectory(YOUR_THIRD_PARTY_PACKAGE) in your main workspace CMakeLists.txt file.
Note it took me quiet some time to fix the compiling process, but finally the third_party project is installed with no .so file and no local library installation.
I need to use python3.7m instead of default python3.8 in my buildroot project. Is there a solution for that or only way is get older buildroot version?
You do not have to downgrade Buildroot. You can always add a custom python3 package based on an older version, e.g.: https://git.busybox.net/buildroot/tree/package/python3?id=b3424c8fc9d1199f5836483f15af48b56373609e
Here the documentation on how to add a package:
https://buildroot.org/downloads/manual/manual.html#adding-packages
One possibility is to add a custom package with a different python version, as #Ezra Bühler explained. However, that custom package must have a different name than python3, which means that you also need to make custom versions of all packages that use python3.
Therefore, a simpler possibility is to modify the Buildroot code itself. There's normally no need to go back to an older Buildroot version - instead, you can take just copy and overwrite python3 from an older version that still has python 3.7. Of course, this is a completely untested configuration so you might encounter some breakage, but it's usually doable. If you take that route, you'll want to also update python to the latest (currently python 3.7.11).
I need a few changes to the ra-core package of the react-admin monorepo on my productive environment.
Can I tell a lerna published module to use my own published module as a submodule instead of it's own?
It's about this package:
https://github.com/marmelab/react-admin
https://www.npmjs.com/package/react-admin
I'm about to create a PR to maybe have these changes merged into the project itself, but I can't know when it will be merged and / or whether it will be even accepted.
But unfortunately I need these changes immediately and it's okay for me to use a fork of mine until it's clear what happens to the PR.
I tried to fork a new ra-core package and use this in my package.json, but this doesn't work. Locally linking is no problem, as I can link it directly in the react-admin module, but I need it in my production build process.
So I'm wondering if there is some way to tell the module in my package.json (react-admin) which comes with it's own subpackages to use one package that I provide in the package.json instead of it's subpackage.
I've created repository where I store my own packages.
System uses my and some other public repositories.
So now I've a package in my repo which I want to be as an update for some other package from another repository.
The repositories are rpm package based.
Is it generally possible to mark my own package to update another package ?
(I would have made this a comment on the previous answer, but its too long.)
There's a problem with using the same package name and just bumping the version number.
Eventually the original package may increase its version number past what you're using, in which case someone may do a yum update and end up upgrading back to the original package.
To avoid this problem, you can change the package name slightly, and add some Obsoletes and Conflicts dependencies to your spec file. The Obsoletes dependency allows the original package to be upgraded to your package, while the Conflicts keeps the original package from being installed at the same time as your package.
This should keep an upstream version bump from clobbering your changes.
See http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-dependencies.html
Going to answer to my own question, yes yum treats all repositories equally. So all I need to do was setting package name the same and increased version number.
To test it you just need to create a yum repo and setup yum to use your repository for more info look here
I'd very much appreciate anyone sharing best-practices, patterns, anti-patterns, backup, rollback processes that you have formulated for a pain-free, foolproof, Play framework upgrade.
I'm thinking just replacing the bin/play directory with the latest version can cause problems
Edit:
I'm looking for more specific version management strategies, say,
a) Do you just have /bin/play directory having the latest play version or
b) Do you keep versions like /bin/play-1.1 /bin/play-1.2 and change your $PATH to point to the latest (cons: you have to rebuild your modules, dependencies & libs; pros: gives better control over rollback)
I prefer to install play from source using git:
git clone git://github.com/playframework/play.git
cd play
# checkout specific version
git checkout 1.2.1
cd framework
ant
cd ..
ln -s $PWD/play ~/bin
So I have a full install including all source. Later, when play was updated to version 1.2.2 I did the following:
cd <play_home>
git pull
git checkout 1.2.2
cd framework
ant
In your application you then do
play clean && play run
The advantage of running play from a source build is that you can always and easily roll back to the previous version or even test out features from current development. This does not solve the problem of having multiple versions of play active at the same time though.
I agree with Andre. However, if you are asking for best practice for a live project, I would do it differently.
You can have multiple version installed on your local machine. The only thing you have to change is which one is visible in the path. For instance you could have 1.1, 1.2, 2.0 and depending on which one you want, you just modify your /home/youruser/.bashrc file.
The reason, why simple update of play from git or hg will not work/good idea is because, incase there are problems, you have to revert, rollback modules, or goodness know what not.
It is far better to simple swap out the play version, rebuild, test extensively, once you are ok that everything is good, then you can make the same changes in a live site.
If things don't workout, or your are hopelessly lost, all you have to do is revert the changes to your project and switch the play version. You will be back to where you started.