Internet research indicates that one can remove the Cygwin package files to save space. Within the Cygwin installation folder, I have a subfolder (say) http%3a%2f%2fcygwin.mirror.constant.com%2f reflecting the mirror site. The file http%3a%2f%2fcygwin.mirror.constant.com%2f/x86_64/setup.ini seems to contain all the information about installed packages. The only other folders/files are in the following two folder trees:
http%3a%2f%2fcygwin.mirror.constant.com%2f/noarch/release/*
http%3a%2f%2fcygwin.mirror.constant.com%2f/x86_64/release/*
Can I remove everything in the http%3a%2f%2fcygwin.mirror.constant.com%2f folder tree except http%3a%2f%2fcygwin.mirror.constant.com%2f/x86_64/setup.ini and still have the installer know what I have installed, what needs updating, and what needs downloading for a re-install?
The information about installed package is stored in
/etc/setup/installed.db
the cache in http%3a%2f%2fcygwin.mirror.constant.com%2f
is only needed during installation or re-installation of any package.
See info in the Cygwin User Guide
https://cygwin.com/cygwin-ug-net/setup-net.html#setup-localdir
After installing Cygwin, the cache is no longer necessary, but you may
want to retain the packages as backups, for installing Cygwin to
another system, or in case you need to reinstall a package.
Related
I'm packaging a PyQt application for Linux as a .deb package, following the Debian maintenance guide.
The manual does a good job describing how to build the python binaries with debuild -b, and install global data files in /usr/share/<package>/ through the debian/install file. However, I don't see any mention of installing user settings files - cache files or files for configuration changes that the current user running the program might want to save.
As far as I understand, other programs usually save these in a hidden directory on the users home path - eg atom's user data in /home/<username>/.atom/.
The manual does mention conffiles. However these seem to be globally installed. I'm also not sure if they're suitable for config files that change frequently as a result of user actions, since package updates will attempt to solve conflicts between new and existing conffiles.
Some other documentation mentions postinstall scripts, but this seems potentially too complicated for something that should be common to many debian packages?
Currently I am trying to install a rpm secured_soft_2.0.0.rpm and i am
unable to install it as we already have secured_soft_1.3.0 installed.
Requirement is that we need to have both the versions installed.
Complexities :
These package inturn have dependent rpm's (lot of them ) and all these
interdependent rpm's also have versions
ex: secured_soft_1.3.0 works only with packages which are of version 1.3,
and secured_soft_2.0.0.rpm work only with dependecies of version 2.0 only.
So all these dependencies also need to be reinstalled and even these
dependenies should be parallely installed, without deleting old.
Finally , both these versions contain shared libraries and these shared
lib's do not have version numbers in their name.
#rpm -ivh secured_soft_2.0.0.rpm
error: Failed dependencies:
init-class >= 1.4.17.1-1 is needed by secured_soft_2.0.0.rpm
init-connection-interface >= 2.0.11.0 is needed by secured_soft_2.0.0.rpm
init-logger >= 2.0.11.0 is needed by secured_soft_2.0.0.rpm
init-security >= 2.0.11.0 is needed by secured_soft_2.0.0.rpm
As i have specified we already have secured_soft_1.3.0.rpm installed and
above dependencies are also available but of different version.
So we need the to install above dependencies and also need the old version's
of dependencies for the old rpm's to work
ex : secured_soft_2.0.0.rpm has libArt.so libSec.so and so on
which are copied to /usr/lib
Similarly secured_soft_1.3.0.rpm also has libArt.so libSec.so and so on
which are already available in /usr/lib
I tried to rename the so's but still iam not able to install.
Is it possible to change the location for these so's and get the things done
Is there any way we can do it.
At the moment, iam stuck here and would need advice on this
Appreciate any help on this.
Since the programs use the same filenames, and you need to put them on the same machine, you might be able to move the older version to another directory tree and make it work there.
You can do this with many applications which do not have compiled-in pathnames.
For instance,
install the older version (this sounds like where you are starting from)
use rpm -ql for each of the packages containing unversioned executables, libraries and associated files.
use tar to capture an archive of those files, relative to /usr (but omitting directories not owned by the packages).
create a new directory, e.g., /usr/local/myapp and untar the older version there.
update configuration files in the new location as needed
For applications such as this, I would run in a script that updates PATH (and perhaps sets LD_LIBRARY_PATH) to force the program to run from the new location. You can verify if this works using tools such as strace and lsof, i.e., by looking for the files that the program opens.
Once you have the older version working properly in the new location, you can uninstall its rpms and install the new version of the application.
Caveat: If the newer package is copied from a newer version of the operating system, however, the task is likely to be beyond your ability, whether or not you choose the alternative approach of recompiling the newer packages to fit on the existing system.
Building new/custom packages is one route to recompiling the newer version. If you have the source-RPMs for each part, that is a starting point:
extract the files from the source-RPM, e.g., using a script such as unrpm (see for example HowTo: Extract an RPM Package Files Without Installing It), and
copy those extracted files to their as-expected locations in your build-tree, e.g., $HOME/rpmbuild/SOURCES and $HOME/rpmbuild/SPECS
modify the spec-file to use the alternative location
build the new/modified package using the modified spec-file.
No, out of the box, you cannot.
I'd highly recommend looking into Docker, where you can throw each one into their own container and let them take care of all their dependency problems.
I need to install a YUM package(OpenNMS) on a server that doesn't have internet access. Is there a clean way to download all dependencies on a server with internet, package it , export it and install it on the server?
Yes/no: there are some limited tools available, and a few problems.
On your server, you can use yumdownloader (or a Downloadonly plugin for yum of yum) to create a local repository of packages. With either approach, you would download the package along with its dependencies.
This process is mentioned in
Download all dependencies with yumdownloader, even if already installed?.
yumdownloader vs repotrack
There is a caveat: my experience is that the tools can be confused by the presence of existing packages on your server (i.e., installed) and will often overlook those in the actual download. One way to work around this is to reprocess the list of downloaded files (asking for their dependencies) to check if no further files will be downloaded.
Of course, if successful, you will end up with a large number of packages (including glibc). However the alternative would be to use the dependencies known to rpm -qpR, which require a lot of work to be useful.
I develop a software which is distributed and installed via rpm. During install, I copy some binaries to a destination directory.
When performing rpm upgrade, I'd like the old binaries not to be deleted, and that the new ones will be added as is.
Is there an rpm built-in way to do so? I'd really like to avoid scripting in order to resolve that...
EDIT:
The above binaries were listed in #files section.
If you are manually copying the files to some directory (in %post for example) then yum/rpm doesn't know anything about them and can't remove them.
If you have them listed in the %files section (i.e. copying them to the right place under buildroot during `%install) then no, I do not believe you can have rpm leave files not listed by the new package on the system after upgrading to a newer version of the package which does not contain those files.
It might be possible to play with marking them as %config files and then "modifying" them so that rpm won't remove them but it might still rename them and I don't know if this will actually work.
I´m doin a unattended cygwin installation and I was wondering if there will occure any problems without a setup.ini.
Following: my "install-folder" includes a setup.exe and a subfolder release (within all the packages packed).
I´m starting the setup silent (with Nsis) and install the packages. In NSIS I define the Root, the location of the packages etc.
I think it works so far (I´m not sure because i´ve got a curious error in cmake). There are many instructions how to modify the whole setup for an offline installation. But I don´t get the point why I have to modify it at all.
I hope anyone has got experience with this issue!
#Daniel Le cygwin installs the packages without the .ini (all of them). And there has nothing to be downloaded because the packages are on the local machine.
I believe the setup.ini is essential to the setup process, as it indicates which packages to be downloaded and installed.
The Ini file is so far only a description for file locations and paths to be set as default. It is not necessary to have the ini file if you wanna install some packages!
That´s my conclusion.