I want to recreate my system as it was a month ago, but if I run "bower install" now, even with the bower.json I had a month ago, it may install different versions of the components than it did a month ago.
So I figure I need to generate a snapshot of version numbers of what bower has installed, a simple text file is fine, and then later be able to tell bower to install all those versions. Is there a way to do this with bower?
Closest I can come is running "bower list" for a snapshot and then writing a fancy shell script that can parse that, pull out components and version numbers, remove repeats, and "bower install" each one.
Related
I can't seem to find anything useful in the man pages etc for this, but it seems like it should be straightforward..?
Our servers are running CentOS 6.8 but also have the Atomic repository for some package versions. The most recent version of one of the packages that Atomic provides seems to be broken, so we've had to do a yum downgrade of that package.
Problem now is that we're running Plesk, which performs automatic Yum updates on a schedule, and the next time this happens, the broken package will just drag back in again!
All I want to do is tell Yum to ignore this specific package version so that it updates the next time there's a newer version, but skips the current.
I found that I can add exclude= lines to yum.conf but I can't seem to find how to define a specific version number in this exclude. It looks like I can only exclude entire package names?
I'm more familiar with Gentoo where we can tell Portage to mask specific versions when problems like this occur. Is this not an option in CentOS?
Much appreciated.
The production code runs in a virtualenv.
The packages and the version numbers should be dumped regularly, to see if there was a version change.
Use case: the application does not behave like it should, and you need to find the source of the problem. It should be easy to see if there were changes (for example new packages).
I know pip --freeze and I know how to write a cronjob .... but somehow I think there could be a better solution.
I have an install.ps1 script in my NuGet package. This script runs both during a new install (after all the files have been copied) and during an upgrade.
I want to show a Getting Started page during a new install, but for an upgrade I want to show the Release Notes.
I found this great answer that tells how to open a URL and it works great. But I am stumped on trying to tell the difference between a new install and an upgrade.
The best solution I have come up with so far is to add a Release Notes link to the top of the Getting Started page, but that is something that could easily be missed by upgraders, and is an unwanted distraction for new installers.
I don't think it's possible to know if the current operation is install or upgrade. When NuGet upgrades a package, what NuGet does is basically uninstall the existing package and install the new package.
I suppose you could do something with install.ps1 that "dirties" the project in some way on the first install, which you will not clean up with uninstall.ps1. Maybe insert a dummy file into the project (outside of the normal NuGet handling, so the file won't get uninstalled automatically) or add some other dummy element to the project file. Then, when you see those "leftovers" from a previous install (which were purposely not cleanly uninstalled), you will know that you are installing an upgrade.
I installed virtualenv + virtualenvwrapper via virtualenv-burrito. However, it seems to be giving me problems now in uninstalling packages from my virtualenvs (case in point, distribute).
It seems that the distribute used by my virtualenvs is the one at /home/skrd/.venvburrito. If, inside a virtualenv, I try to upgrade distribute, it installs to /home/skrd/.virtualenvs but the virtualenv itself is still using the one at /home/skrd/.venvburrito. With that, the packages needing an updated distribute still won't work.
See,
(test)$ $ pip uninstall distribute
Not uninstalling distribute at /home/skrd/.venvburrito/lib/python/distribute-0.6.27-py2.7.egg, outside environment /home/skrd/.virtualenvs/test
I've tried renaming the .venvburrito directory (equivalent to deleting it, but with back-up) but that breaks my virtualenvs. How do I uninstall packages now?
I still don't understand what happened here but I just had the idea to check what's installed for my system's Python outside virtualenv. There I saw distribute, with a similar version to the one that's giving me problems inside a virtualenv.
I upgraded the non-virtualenv installation of distribute and, next time I checked in my virtualenv, the distribute installation has also upgraded.
(So, yes, I'm aware that my question's original intent is to remove distribute. But that was just an intermediary step to updating it---the update was unable to proceed since it can't remove the distribute currently installed. So, there, problem solved.)
I have currently installed a version of rpm (x.rpm) that needs to be renamed in the next version (y.rpm). To accomplish this, I decided to obsolete the old (x.rpm) rpm. When I run the rpm –Uvh y.rpm on the new rpm here are the steps that takes place:
-Pre-transaction
-Pre-install
-Post install
-Pre uninstall
-Post uninstall
However, my post-uninstall script has some clean up steps that goes and does an rm –rf for some folders. The post-uninstall for both version of the rpm is exactly the same so now, when I installed the new rpm (y.rpm), some folders that were required by the new version gets removed because of the post-uninstall script.
How do I get around this issue?
Any help is greatly appreciated.
Thank you.
Here is what i would do:
create a newer version of x.rpm with changed post uninstall script that doesn't remove folders
update x.rpm on all machines
wait for a while (depending if this is an in-house project or an open project on the internet)
start deploying y.rpm