During Minor Upgrade in InstallShield 2011, how to delete/remove some files which was installed from base installer and for next upgrade if we want to retrieve back the removed files how can we get back?
Overall Suggestion: Use one file per component. This avoids all kinds of component referencing problems and you can resurrect
files on major upgrades if you need to bring them back after removing them.
Note that you generally cannot switch directly to using major upgrades if you have prior releases without wiping the slate clean and installing to a different location overall. Changing the installation directory and using new component GUIDs for all files wipes the slate clean and you are decoupled from old component referencing sins.
Minor Upgrade Limitations: Minor upgrades are very restrictive with regards to what they allow you to do in an upgrade scenario. I have written a summary of this before, and I will send you there for a quick read on the topic.
Quick Tips: I almost never use minor upgrades (for reasons that are clear after you read the above linked answer), but here are some extracts from Stefan Kruger's check list (MSI and deployment expert - MVP):
You can modify the contents of a component (add, remove or modify files, registry keys and shortcuts), but only if that component is not shared across features.
If you remove a file or registry key from a component, you must populate the RemoveFile or RemoveRegistry table respectively to delete the orphaned resource.
Though aging content, I believe the above is correct.
Major Upgrade: I would strongly recommend that you go for major upgrades in the future. If you are very strict with the component rules and don't break any referencing rules, you can reliably install major upgrades with Late REP - as we call it - meaning that the new version installs as a patch on top of existing files and then only removes obsolete files (as opposed to Early REP which fully uninstalls the old version and then installs the new version). A little bit more on Early / Late REP here.
Links:
Configuring Minor Upgrades to Remove Installed Data
http://www.installsite.org/pages/en/msi/updates.htm
Identifying When to Use Major and Minor Upgrades
Is there any possible way to perform upgrade when Product codes for old and new versions are same? (same as above, but original title)
Easily adding/removing files within a Minor update
Restarting windows service during WIX upgrade
Related
I've done a bit of googling and haven't been able to find any documentation on this, but I need to upgrade my Seeddms (Document Management System) server from 5.1.25 to 6.0.19.
I am running a Linux Lamp 4.19.0-19-amd #1 SMP Debian 4.19.232-1 (2022-03-07) with a Seeddms web server on it.
I tried copying the contents of the .gz download file of the latest version over my current /var/www/html/dms/ folder and it didn't work, I did a similar thing to update my dokuwiki site so I thought I'd give it a try here.
I am still new to Linux so any advice would be greatly appreciated!
I was able to find the solution, in the seeddms-quickstart-x.x.x/seeddmsxxx/seeddms-x.x.x/doc/README.Install.md.
Here is what is says on upgrading versions if anyone has trouble with this as well. Make sure your server meets the requirement as well.
UPGRADING FROM A PREVIOUS VERSION OF SEEDDMS
As SeedDMS is a smooth continuation of LetoDMS there is no difference
in updating from LetoDMS or SeedDMS.
You have basically two choices to update SeedDMS:
you install a fresh version of SeedDMS and copy over your data and configuration
you replace the software in your current installation with a new version
The first option is less interuptive but requires to be able to set up a second
temporary SeedDMS installation, which may not be possible, e.g. because of storage
limitations. It can be the only option if you change servers.
The first update procedure is only needed if the version changes on the minor
or major version number. Changes in the subminor version number will never
include database changes and consequently it is sufficient to use the existing
data directory and database with the new version. Choose the second update
option in this case.
In both cases make sure to have a backup of your data directory, configuration
and database.
Fresh installation and take over of data
The first update option is to set up a new instance of SeedDMS and once
that is running take over the data from your current (old) instance.
just do a fresh installation somewhere on your web server and make sure it
works. It is fine to use
SQLite for it, even if your final installation uses MySQL.
replace the data directory in your new installation with the data directory
from your current installation. Depending on the size of that directory (and
whether the new installation is on a new server or the old server) you
may either copy, move or place a symbolic link. The content of the data directory
will not be changed during the update. Its even perfectly save to
browse through your documents and download them after finishing the
update. The data directory will not be modified until you actually modify
documents.
copy over the configuration settings.xml into your new installation. This will
effectively make your new installation use the data from your old installation,
because all paths are still pointing to the old installation.
if you use mysql you could as well make a copy of the database to make sure
your current database remains unchanged.
modify the settings.xml to fit the environment of the new installation.
This will mostly be the
httpRoot, the paths to the installation directory and possibly the database
connection.
create a file ENABLE_INSTALL_TOOL in the conf directory and point
your browser at http://hostname/seeddms/install
The install tool will detect the version of your current SeedDMS installation
and run the required database updates.
If you update just within the last version number (e.g. from 5.1.6 to 5.1.9),
this step
will not be required because such a subminor version update will never
contain database updates.
Upgrading your current installation
Instead of setting up a new installation, you may as well replace the php files
in your current installation with new versions from the quickstart archive.
get the SeedDMS quickstart archive seeddms-quickstart-x.y.z.tar.gz and
unpack it somewhere on your disc.
copy the directory seeddms-x.y.z from the unpacked archive into your
current installation and make the link seeddms point to this new directory.
copy the directory pear from the unpacked archive into your current
installation, replacing the existing directory. Make a backup of pear before
the replacement if you want to ensure to be able to go back to your old version.
you may compare your conf/settings.xml file with the shipped version
conf/settings.xml.template for new parameters. If you don't do it, the next
time you save the configuration the default values will be used.
create a file ENABLE_INSTALL_TOOL in the conf directory and point
your browser at http://hostname/seeddms/install
The install tool will detect the version of your current SeedDMS installation
and run the required database updates.
If you update just within the last version number (e.g. from 5.1.6 to 5.1.9),
this step
will not be required because such a subminor version update will never
contain database updates.
In Installshield 2015 Premier Edition, I've created a patch definition which upgrades my application product from version 1.9.7 to 1.9.7.5
In the Installscript MSI project, I've only changed package code, product version and built the patch (Latest 1.9.7.5 release - Previous 1.9.7 release).
Patch (Update.exe) is executed under Admin priviliges (a 1.9.7 release in installed priorly)
The patch 1.9.7.5 will omit to update .exe and .dll component files of a feature application directly install in [INSTALLDIR] (root : C:\ProgramFiles\MYCOMPANY\MYAPP\confapp.exe)
All other component files are updated respectfully ; they're located in their own sub-directories of [INSTALLDIR] as designed in Installation Architecture in IS2015.
C:\ProgramFiles\MYCOMPANY\MYAPP\Feature1DIR\app1.exe
C:\ProgramFiles\MYCOMPANY\MYAPP\Feature2DIR\app2.exe
C:\ProgramFiles\MYCOMPANY\MYAPP\Feature3DIR\app3.exe
C:\ProgramFiles\MYCOMPANY\MYAPP\Feature4DIR\app4.exe
C:\ProgramFiles\MYCOMPANY\MYAPP\Feature5DIR\app5.exe
I'm shipping the newly built applications and have upgraded my .dll files with AssemblyInfo.cs.
Long story short, my Update.exe is only updating 5 out of 6 applications installed.
Any help appreciated if you've already encountered the issue,
Regards,
Can you please add your feature/component/file structure and log file entries that relate to those files in particular? It should look something like:
MSI (s) (B4:4C) [11:30:07:906]: Executing op: FileCopy(SourceName=eulatxt|eula.txt,SourceCabKey=FILE1,DestName=eula.txt,Attributes=512, FileSize=29239,PerTick=32768,,VerifyMedia=1,,,,, CheckCRC=0,,,InstallMode=58982400,HashOptions=0, HashPart1=-1713153497,HashPart2=58557210, HashPart3=1046945815,HashPart4=871163290,,)
MSI (s) (B4:4C) [11:30:07:906]: File: C:\WINDOWS\system32\eula.txt; Won’t Overwrite; Won’t patch; Existing file is unversioned but modified
You also need to check your components and key files. If the key file for a component is not changing in your patch (this is a "small update" or "patch" BTW, not minor upgrade), none of the other files in the component get upgraded regardless of the version changes associated. Remember that component best practices state one binary (versioned) file per component.
From this MSDN article:
Be aware how the Windows Installer applies the File Versioning Rules
when Replacing Existing Files. The Windows Installer first determines
whether the component's key file is already installed before
attempting to install any of the files of the component. If the
installer finds a file with the same name as the component's key file
installed in the target location, it compares the version, date, and
language of the two key files and uses file versioning rules to
determine whether to install the component provided by the package. If
the installer determines it needs to replace the component base upon
the key file, then it uses the file versioning rules on each installed
file to determine whether to replace the file.
If this is an InstallScript project, open Components view and make sure OverWrite setting is set to Always. By default, it is set to Overwrite files by version, then Date, I think. However, I have seen cases when this algorithm did not work for some reason, and some files were not updated.
As a newbie with phpBB forum (3.1), I understand that modes may change data in forum database and files.
Therefore, I would like to backup the site before mode installation, so that the previous state could be easily restores in case it is necessary.
What are the exact instructions to install and de-install modes safely?
I'm guessing you mean 'Mods' instead of 'modes'?
phpBB v3.1.x does not use Mods like the old 3.0.x branch where core code needed to be changed. Instead it uses extensions which are uploaded to your server and simply activated in your ACP.
As a precaution it is always advised to back up your database before making any changes to your site.
Full instructions are on the phpBB sie here - https://www.phpbb.com/extensions/installing/
I had downloaded cygwin from one mirror site, and after a few months when I try to update now I get the message that the "current ini file is from a newer version of setup-x86_64.exe"
If I download a new ini file, does it also mean that the entire cygwin installation will have to be downloaded again? That will take a huge time and I would like to avoid it.
Also, what is a stable mirror site for cygwin? On some update occassions, I have got the message that the site is no more a "recommended" site, and I should select another mirror site.
The answer to your main question is NO. That message appears because the setup-x86_64.exe file has been updated. You need to download a recent version at http://www.cygwin.com/setup-x86_64.exe.
Mirror sites are updated on a schedule, so the updates at mirrors are always behind the main Cygwin site by a certain amount. Some sites update more frequently than others. From the Cygwin mirror admin site:
Given the granularity of checking, it is possible that your site will
be polled after a package update on cygwin.com but before your site
has pulled the update. So, it is expected that from, time-to-time,
your site may fall off the mirror list temporarily. If your mirror
site has not been listed for a day or so that means that some cygwin
packages on your site are not current. Check the cygwin-announce
archives for announcements about recent package updates and ensure
that your site has those packages. Once your site has the recent
packages it will be re-added automatically.
and
So, if your site was dropped from the list it means that a program has
determined that the files on your site are not up-to-date. Unless your
site has been out of date for (currently) 100 runs of the program, it
will be re-added automatically when it becomes current. So, if you see
that your site has been dropped from the mirrors list do not panic.
I’ve generally found that unless you repeatedly get the message about it not being a recommended site, there's nothing to worry about, just try again in a few hours or the next day. Picking the site closest to you is generally a good bet.
You just need to download a newer version of the setup.exe file and perform the update with that.
During the setup you'll be presented with a list of recommended mirror sites, choose one near to you and you're good to go.
No worries. :-)
I have several applications that I wish to deploy using rpm. Some of the files in my application deployments override files from other deployed packages. Simply including the new files in the deployment package will cause rpm conflicts.
I am looking for the proper way to use rpm to update/replace already installed files.
I have already come up with a few solutions but nothing seems quite right.
Maintain custom versions of the rpms containing the original files.
This seems like a large amount of work for a relatively small reward even though it feels less like a hack than some of the other possible solutions.
Include the files in the rpm with another name and copy them over in the post section.
This would work but will mean littering the system with multiple copies of the files. Also it means additional maintenance in the rpm build spec for each file.
Use wget in the post section to replace the original files from some known server.
This is similar to the copy technique but the files wouldn't even live in the rpm. This might act like a nice central configuration authority though.
Deploy the files as new files, then use symlinks to override the originals.
This is also similar to the copy technique but with less clutter. The problem here is that some files don't behave well as symlinks.
To the best of my knowledge, RPM is not designed to permit updating / replacing existing files, so anything that you do is going to be a hack.
Of the options you list, I'd choose #1 as the least bad hack if the target systems are systems that I admin (as you say, it's more work but is the cleanest solution) and a combination of #2 and #4 (symlinks where possible, copies where not) if I'm creating the RPMs for others' systems (to avoid having to distribute a bunch of RPMs, but I'd make it very clear in the docs what I'm doing).
You haven't described which files need to be updated or replaced and how they need to be updated. Depending on the answers to those questions, you may have a couple of other options:
Many programs are designed to use a single default configuration file and also to grab configuration files from a .d subdirectory. For example, Apache uses /etc/httpd/conf/httpd.conf and /etc/httpd/conf.d/*.conf, so your RPMs could drop files under /etc/httpd/conf.d instead of modifying /etc/httpd/conf/httpd.conf. And if the files that you need to modify are config files that don't follow this pattern but could be made to, you can suggest to the package maintainers that they add this capability; this wouldn't help you immediately but would make future releases easier.
For command-line utilities like sendmail and lpr that can be provided by multiple packages, the alternatives system (see man alternatives) permits more than 1 RPM that provides these utilities to be installed side by side. Again, if the files that you need to modify are command-line utilities that don't follow this pattern but could be made to, you can suggest to the package maintainers that they add this capability.
Config file changes on systems that you administer are better managed through a tool like Cfengine or Puppet rather than through custom RPMs. I think that Red Hat favors Puppet.
If I were creating the RPMs for systems I don't administer, I'd consider using a third-party tool like Bitrock and dumping all of my stuff under /opt just so I wouldn't have to stomp on files installed by other admins' RPMs.
Edit (2019): Nowadays, Software Collections offers a useful alternative. You can create packages that install somewhere under /opt, and the Software Collections tools offer a standardized way for users to opt in to using those instead of whatever's normally installed under /usr. Red Hat uses this to distribute newer versions of tools for their otherwise stable and long-lived (i.e., older) Red Hat Enterprise Linux distributions.
You can also execute rpm -U --replacefiles --replacepkgs ..., which will give you what you want.
See here for more info on RPM %files directives:
http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html
You can use the arguments from the %post and %pre sections in the RPM scriptlets to determine if you are installing, upgrading or removing packages.
If $1 is 0 - then we're removing old stuff. Targeting 0 packages installed.
If $1 is 1 - then we're installing new stuff. Targeting a total of 1 package to be installed.
If $1 is 2 or more - then we're upgrading this package and $1 represents the number of packages already installed.
These sections help with managing files among the versions.
Keep track of what you're doing between versions and consider what one might do if they were to skip a version or two.
Have consideration for these things and you should be good to go!