What is the database format of MSYS2 Pacman package cache (msys.db, mingw32.db, etc.)? - msys2

MSYS2 uses pacman as its package manager, which caches available packages locally in files /var/lib/pacman/sync/<reponame>.db (such as msys.db). What is the database format of those files?

"The pacman databases are normally located at /var/lib/pacman/sync. For each repository specified in /etc/pacman.conf there will be a corresponding database file located there. Database files are gzipped tar archives containing one directory for each package." (See pacman database structure)

Related

Need to check where reposync is saving the .rpm files

I am working in a yum repository that is for RHEL6 (This is our copy of the RHEL6 yum repo).
I need to do reposync so that this server can get the latest version of all the packages.
I need to know in which all the rpm packages are getting saved.
Like is there any file that can let me know whenever I am running reposync where the .rpm files are saved?
In short, I want to know, how can I know the name and location of all repositories that my server is hosting. And where the repo files are getting saved.
I have tried looking for the solution on StackOverflow and other sites. I am getting information on how to create a new repo but I couldn't find the answer that I want.

How to update a pip package without resetting its CSV files to its original state

I'm trying to publish my own pip package that contains a few CSV files that are going to be filled with continuous user use. I tried to do test update to my PyPI package and noticed that the CSV files get reset to their original state. How do I release new versions of my pip package without affecting/resetting some file types such as the CSV files?
Currently, my MANIFEST.in file contains the following line
graft package
And within the package directory, there is a bunch of Python and CSV files.

CentOS6 - Backup all RPMs and installed programs

Is there away to backup all installed applications/RPMs/packages/ (even repositories) as is (with same exact versions/patches) on 1 script that can re-install them on a fresh bare bone server of the same specs
Note: I can't do any image or CloneZilla tricks
Note: there are some 3rd party software that is not offered by any repos ... solution should contain a backup of these packages (preferably all)
thanks!
As noted in a comment, you can backup the RPM database, but that is only one part of replicating your configuration to another server:
RPM's database records almost all of the information regarding the packages you have installed. Using the database, you could in principle do something like a script that used cpio or pax to append all of the files known to the RPM database to a suitably large archive area. rpm -qa gives a list of packages, and rpm -qlpackage gives a list of files for the given package.
However, RPM's database does not necessarily record files created by package %pre and %post scripts.
Likewise, it does not record working data (such as a MySQL database) that may be in /var/lib.
To handle those last two cases, you are going to have to do some analysis of your system to ensure that you do not leave something behind. rpm -qfpathname can tell you who owns a given file- or directory. What you have to do is to check for cases where RPM does not know who owns it.

Creating a WiX patch from single file location

I am trying to create a patch for my application. Implementing the example described here worked as expected. However, the files for each version are stored in separate directories. Version 1.0 files are in c:sample\1.0 and 1.1 files are in c:sample\1.1. If I move the files to a single location, create the 1.0 installer, modify the files, and create the 1.1 installer; wixmst output of torch contains no differences. When I run pyro I get:
warning PYRO1079 : The cabinet 'media1.cab' does not contain any files. If this patch contains no files, this warning can likely be safely ignored. Otherwise, try passing -p to torch.exe when first building the transforms, or add a ComponentRef to your PatchFamily authoring to pull changed files into the cabinet.
This is a problem for me because the files for my project are kept in a single git repository. We use branching and tagging to delineate versions. Because of this I only have one directory of files.
I have the .msi and .wixpdb for both versions.
How can I create my patch in this situation?
Pyro requires access to the .wixmst and the old and new files. If you only have one set of files (newer or older) then the patch will obviously find no file differences. That is why you are getting the error from Pyro.
If you use bindpaths to create the original .msi files (and their .wixpdbs) then you can provide the old paths using the -bt switch to pyro and the new paths to the -bu switch. If you didn't use bindpaths and you need to recreate the old directory structure for the old files and create a new directory structure for the new files.
If you can't get the old and new files to be found (bindpaths work best) then you'll have to do admin image type patching.

How to download a bazaar repository with revision history without using the "bzr" Command Line Interface?

I tried downloading the bazar repository from launchpad with revision history using:
bzr branch lp:<repo-name>
This repository includes the .bzr directory which contains the revision history.
However launchpad.net also shows an option of downloading the zip file for some repositories.
The zip file does not contain the .bzr directory. It just contains the source snapshot of the latest version.
In github it is possible to download zip files with complete git revision history (ie. the .git directory is present)
I was wondering if this is possible in Launchpad?
No, I don't think Launchpad has such feature. The zip files you see are packaged by the project owners, not something generated or automatic. They could package zip files including the full history but the purpose is usually the opposite: a release version of the project with no history, only the files.
If you want a zipped version of the full history, you have to do it in two steps: branch and then zip up.
The --no-tree flag might be useful for you. Using that flag with the branch command will create only the .bzr directory without the working tree (the project files).