I am doing a concept in linux in which i want to do version rollback for an app installed in linux. Is it possible??
For eg I have an application named X with version 1.1
I get an update. It changes it to version 1.2
I note what all the packages in the app going to be modified.
Then i save them and apply the changes.
Now after sometime due to some problems I want to switch back to version 1.1
If i undo the changes and make the entire solution will the rollback be done?
The easiest and common way in Unix is to install them in separate directories,
eg "/usr/bin/MyApp.1.2.3" and "/usr/bin/MyApp.1.2.4" then create a link to the one to use "/usr/bin/Myapp".
Changing versions is then just a matter of moving the link.
You don't need to invent anything. Just keep the packages you install around. If you want to go back, uninstall the current version and install the previous package again.
Related
We build our installs\releases using Install Shield. I have come to a situation where we have a patch that cannot be upgraded by a release with a higher version number, that is missing components included in the patch.
After releasing a full minor release (i.e. 7.2.0) we released a patch on a previous full minor release (i.e. 7.1.12).
The Patch 7.1.12 had files and components added that do not exist in 7.2.0. The patch is not uninstallable.
It is now impossible to upgrade 7.1.12 to 7.2.0 because of the missing components. Some customers specifically want to upgrade to 7.2.0 and not a later version (7.3.0) where the components can be added to fix the issue.
Short of uninstalling 7.1.12 and then installing 7.2.0 I couldn’t find any solution to fix.
Is there any way around this? Can we build a 7.1.13 as a bridge to somehow fix the mistake. Or use an argument when installing 7.2.0 to get around this.
I looked around the registry and I am trying to figure out if it is possible to remove the components through the registry.
I tried deleting the component entries in the registry. that didn't do it.
If I delete the product entry in the registry that works - but it must be overkill.
I also tried deleting the patch msi from C:\Windows\Installer but that didn't do it.
There must still be a way to unlink the component from the feature in the registry without deleting the entire product.
It sounds like you're trying to do a series of Minor Upgrades, with at least 7.1.12 delivered as a patch. Using minor upgrades imposes various limitations; anything that requires you to Change the Product Code must be avoided. In your case, note that adding components is allowed, but not the reverse:
The update can add a new component to a new or an existing feature.
The product code must be changed if any of the following are true for the update:
A component is removed from an existing feature.
In short, any modifications to the feature-component tree, other than the addition of new ones, is going to require changing the product code, and thus a Major Upgrade. Major upgrades perform an uninstallation behind the scenes, and thus are less restrictive about the changes they are allowed to deliver.
You have two options:
Use a major upgrade, or some other means of uninstalling the old installation before installing the new version. If possible, this is what I would recommend. Using minor upgrades often adds more difficulty than benefit (though your needs may differ).
Maintain the new components in your newer versions. Note that you do not necessarily have to maintain the resources within them:
The update can add, remove, or modify the files, registry keys, or shortcuts of components that are not shared by two or more features.
But you will have to make additional changes to account for the changes to the resources. In your case, this probably will require additions to the RemoveFile table, and may be best served by "puncture component" pattern.
Spelunking through the registry for a workaround that modifies Windows Installer's bookkeeping is a bad idea. It may work, it may appear to work, or it may not work at all. In no case is it supported.
If both versions 7.1.12 and 7.2.0 are already publicly released, you're in a rough spot. I think your best bet there is to re-release 7.2.0 with a new product code and version, e.g. a 7.2.1 major upgrade. You can advise your end users that those already at 7.2.0 don't need to install it.
As I was going through and locking down specific tag versions in my app's Gemfile, I noticed the origen_updater gem had no version associated with it.
gem 'origen_updater'
Why is that? I see that it is version controlled. Could changes to this gem impact modeling or generation?
thx
No, the only thing this gem does is copy its fix_my_workspace script to the application's bin directory.
See here for more background - http://origen-sdk.org/origen//guides/starting/workspace/?highlight=fix_my_workspace#Fix_My_Workspace
It is not versioned for the following reasons:
The latest version of this script will always be the best, which by definition, will have the best chance of getting your workspace going again if it is in a broken state
This script is intended to be called directly at times when either Origen or Bundler fail to launch. Finding out that you need a newer version of the script to fix your current problem is not very helpful if you are in a state where Bundler cannot be used to pull it in.
Therefore, the recommendation is not to lock this to a particular version and instead allow it to pull in the latest and greatest anytime you do a bundle update.
If I update node or a package, will it affect the applications I have that are currently dependent on the previous node/package version I had? If yes, how do I fix this? Maybe like a virtual environment :)
You should be looking at the update from 2 standpoints.
1. Node itself
2. Updating NPM Packages
For instance, there is the Node LTS which at this time is 6.1.10 and then there is v7.7.3. If you desire total stability then use the LTS. As Cihan said above, upgrading Node can be a long process if you have a system running on an older version.
However, if you want to test out the new async/await (async functions) which is already in 7.7.3 and should be released officially in 7.8 then 7.7.3 is the way to go. But keep in mind some things just may not work as you think they should or you may get some wonky results.
Also be aware depending on your server or system the Node update works differently and make sure you read the documentation for that specific system you need to upgrade.
NPM is a different ballgame. You are reliant upon many different programmers or groups of programmers. The package is depending upon their capabilities and desire to maintain the backwards compatibility. Most package creators are really good about this. Some are not.
Take a for instance. MongoDB issued a really new driver which is an incredible upgrade from its previous one. The new driver contains ES6 and in conjunction with the co package, it is basically operating with promises.
Updating this package for MongoDB was essential for me. But it does maintain my previous code as well, (even though lots of it may be superfluous now!)
So when you think about updating Node..it is not the same as updating NPM modules. But if you wish, you can go to our project root where package.json exists and just type npm update and all packages will be updated. You can update to only a specific version - take a look here.
Remember also, NPM itself also requires updating from time to time.
So in summary:
Node Version - decide which one based upon needs, requirements and your own servers.
NPM as NPM also needs updating from time to time
NPM packages can be updated constantly with npm update or just update to a specific version number based upon the url above.
Not as confusing as it first seems, once one gets it all down straight :)
Good luck
It's possible that you have a package that is being used by another package which a version change could break it. There are several options, if this is a personal project then you would have to either reinstall the correct version of the package or see if there are updates available otherwise for the packages that broke.
It should not, because npm was made to resolve this issue: each project has its own dependencies, and it is totally independent with other projects.
In a word, no matter what you change, you do npm install in your project, npm will fix the dependency issue by itself (by checking your project's package.json)
npm-packages sometimes change or deprecate certain functions & functionalities in newer versions. If something stops working when you update a package, you must figure out from the documentation of the updated package on how to make it work again. Many packages might also give runtime information/errors in the console about functionalities that have deprecated or that have been marked for deprecation in future versions.
npm will download specific versions of a packages' dependencies (and thus you can often have multiple version of a certain package in one project), so you shouldn't need to worry about the dependencies of the packages you are updating, only about the changes of the package itself.
Certain npm-package versions only support certain versions of Node, so updating the node version might require updating some packages. If you switch the node version, it will also switch the npm version, which will then install the correct version of the package per node version.
Some Node.js functionalities might stop working if you update Node.js. In these cases you must refer to the Node.js docs for help. Sometimes updating Node.js from a old version to a new version in a project is a large and tedious task.
i am using Fedora 24. For my thesis, i have to build BlueZ from the source, because I need the experimental features.
Now, what is the best practice? Do I have to remove BlueZ from the OS before I can reinstall it from the source? When i try to remove bluez with dnf, he wanna also remove httpd and other applications as dependencies.
Thanks
Best practice is probably to rebuild the RPM. We have bluez 5.39 in Fedora 23 (and 24) currently — this is one minor release behind the latest. If you need the newest, you could grab it from Rawhide, Fedora's development branch.
Then, modify the spec file to enable the experimental features you need (presumably in this case by putting --enable-experimental on the %configure line.
When you modify the specfile, add something like .experimental.1 to the end of the Release: field. That way, it will be counted as a newer update, and you can dnf update bluez-5.39-1.fc23.experimental.1.x86_64.rpm. (Update that final .1 whenever you make a change, as a form of rudimentary version control.) Then, use the DNF versionlock plugin to make sure updates don't override it, and when new versions come out, update at your leisure.
One of my company's products requires QuickTime. Our installer (made with InstallShield) at the moment attempts to install QuickTime automatically. Unfortunately, if a newer version of QuickTime is installed than the one we package, there is an error saying as much. Normally, this would be a minor inconvenience for our users, but if they run a silent install under these circumstances, the installer simply fails.
I could just update the version of QuickTime we package making it more likely that people do not run into this issue (which we will likely do anyway), but that is still a temporary workaround to the real issue. What really needs to happen is that the installer should check if QuickTime is already installed, and if it is, skip attempting to install QuickTime altogether.
I have looked into “Prerequisites” and “Custom Actions” but I have yet to find anything that would let me accomplish this. Am I looking in the right place? If so, what am I missing? If not, is there another way to accomplish this?
In my attempt to use a Prerequisite, I looked for a Registry Key that seemed sensible to use but it seems that QuickTime does not use a Registry Key to simply declare its current version (at least none that I could find). So, despite the fact that it's not remotely ideal, I tried to run the prerequisite depending on whether or not the file QuickTimePlayer.exe existed in [ProgramFiles]QuickTime\. I did not receive any error output, but on a test machine that had no QuickTime installed, the prerequisite did not run.
How do you choose whether to try to install QuickTime?
Prerequisites are designed to detect if something is present, and, if not, install it. Prerequisites detect the presence of something through their conditions, typically looking for a known registry key or file with version information, and comparing against the version they would install. If it's missing or lower, install it; if it's equal or higher, skip it. But you must use the prerequisite editor to tell the prerequisite what to look for.