If I have the correct git file and there was a change to the configuration file, shouldn’t there be a .pacnew file?
Can anyone shed some light on the differences between the git file and the file installed (either original and/or update), much appreciated. I concentrated on the SigLevel option.
I am more interested in why pacman.conf on my system is different than the one in git, and why no .pacnew. I tried to look through the commits to find when it changed, but so far I have been unsuccessful.
==Test 1: My Current System which was initiated from ISO 21.1.3 ==
I did the following steps:
mkdir temp && cd temp
cp /var/cahce/pacman/pkg/pacman-6.0.1-2-x86_64.pkg.tar.zst .
tar -xf pacman-6.0.1-2-x86_64.pkg.tar.zst etc/pacman.conf
less etc/pacman.conf
And pacman.conf does not contain SigLevel; Same as git.
== Test 2: Install ISO and all updates System ==
However, the ISO I installed from (lsb_release -a: 21.1.3 Pahvo; media: manjaro-xfce-21.1.3-210916-linux513) has a pacman.conf with SigLevel and no update produced a.pacnew. I expected to see a .pacnew somewhere along the lines.
I don’t want SigLevel to confuse the issue, I’m just using it as indicator that the config file changed. I’m more concerned why a changed config file didn’t produce a .pacnew file. I did make changes to the installed pacman.conf (i.e., NoExtract, VerbosePkgLists, etc). This is a simple case with no repercussions. I’m using it as a safe learning experience. I’d like to have a more reliable, long-term way of finding out about changes other than a happy accident in this forum The .pacnew is one reliable, consistent way, or at least I thought it was.
I thought it might be the version of pacman, but the ISO contains 6.0.1-1, and with the most current maintenance 6.0.1-2.
It is my understanding from archwiki that when an update contains a change to a configuration file that has been modified, a .pacnew file will be created so the user can view the changes. I don’t know how that happens under the covers — is it an automated or manual process.
When I look at git, all I see is pacman.conf in the Master Branch. Does every ISO and/or update have it’s own Branch or Tag, so users can follow the changes? HHHHMmmm…
So pacman checks if the file was modified after installation and if was, new config from updating package creates new one .pacnew config file.
AFAIK, if config file was not changed by user, it updates by replacing old one with newer one silently withou user interaction request: it is nothing to merge: was default package config and became default package config - like you just installed new OS copy with that new package already built-in in that hypothetical ISO image.
I made changes months ago to pacman.conf. Prior to changing the file, I copied it to pacman.conf.install, so I maintain the original file.
I expect to see a .pacnew if there are changes to the file from Manjaro. Comparing my pacman.conf and pacman.conf.install to git, I believe there should have been a .pacnew (unless I’m at the wrong git location).
I read a topic that got me looking at things (some times I see if I know the answer to topics without answering to learn and verify what I think I know with the goal of alleviating future problems and sharing solutions). During this process, when I viewed the pacman package on git , I noticed specific options were different from my pacman.conf and even pacman.conf.install. I’m scratching my head , but I never received a .pacnew.
@alven how does your pacman.conf compare to the git pacman.conf?
I tried to find the git commit that removed the 4 lines containing “SigLevel = PackageRequired”, but was not successful.
If I missed the pacman.conf.pacnew, what other pacnews have I missed or will miss in the future that might cause a problem. I’m just trying to follow the source here, to explain the difference. It is a standard reply to tell user’s on the forum to look for .pacnew files after an upgrade.
I always run pacdiff and review the pacman stdout.
I may have to chalk this up to an unexplainable enduser event. Oh well,
Yeah, I did that. Sorry for not mentioning it. The extracted file matches git, which confirms to me that I should have gotten a pacnew because /etc/pacman.conf had changes made to it.
Am I the only one with a changed pacman.conf that hasn’t gotten a .pacnew
I thought I could sneak up on this issue (get a .pacnew when config file is different) by reinstalling pacman (pacman -U /var/cache/pacman...), but it doesn’t seem to work that way (I’m on VM trying this now).
What code causes the .pacnew… Is it just the code in /var/lib/pacman/local/pacman-6.0.1-2/install?
I don’t know enough of C to be able to read it like a book but from what I gather that is implemented in the source code of libalpm, which is a part of the pacman source code.
If you do understand and want to examine, look at the source code:
no /var/lib/pacman/local/*
is the database where all info about all installed packages
that pacman knows about and thus can manage and keep track of
is kept
Were there even any changes in packageetc/pacman.conf for this minor update?
Methinks your situation is this one (see Arch wiki):
original = X, current = Y, new = X
The original package and the new package both contain exactly the same version of the file, but the version currently in the filesystem has been modified. Leave the current version in place and discard the new version without notifying the user.
Even if your local /etc/pacman.conf was different you would not get a pacnew file due to both pacman package files having the same content/md5sum.
It’s browsable online: this function seems to be the relevant one.
I’m leaning less towards pacman and more towards git (or buildiso) at the moment.
Where does pacman.conf come from — when the ISO is built…
Walk’n through the steps with questions
[pacman -Qi pacman] shows the Packager at Manjaro. So now I know to focus on the Manjaro package, and not Arch.
When I install any recent Manjaro ISO and compare /etc/pacman.conf to gitlab.manjaro.org/packages/core/pacman/-/blob/master/pacman.conf, they are different.
I’m expecting to find /etc/pacman.conf that was just installed some place at gitliab. The latest ISO I tried was - manjaro-xfce-21.2.1-220103-linux515
I thought I might build my own ISO, read the source, and see how all the pieces fit and where packages come from. I’m new to these tools, so forgive the hiccups
When the Manjaro ISO is created, are the same tools, like buildiso used?
Is it possible, pacman.conf is coming from a local source, and not git?
NOTE: I’m using pacman.conf to keep it “simple” , but it could be any package with more or less importance in the future, and I’m just try’n to wrap my head around the process to make life easier in the future.
github
I was discussing Manjaro and gitlab and github with another Manjaro user. They thought Manjaro had migrated from github to gitlab. Is the migration complete? Is Manjaro still using github?
No, though some individual developers still have their own code there, so it may be sourced from the PKGBUILDs found at the official source - Gitlab - or rather, Manjaro’s own instance of Gitlab.
It is too bad about Architect. It’s nice, and it is how I finally figured out where pacman.conf came from. I’m definitely going to experiment with buildiso tools.
I read in the forum that users could still install manjaro-architect and this video by OTB was encouraging.
I did install, and sure enough pacman.conf was different.
I examined the ISO and mounted the squashfs’s (MANJARO_XFCE_212/manjaro/x86_64/{desktopfs,livefs,mhwdfs,rootfs}.sfs). Tools used (strings, hexdump, find).
Bottom line, pacman.conf gitlab source location is based on installation method, and the files are different.
That is correct and it is so because Architect installs the packages from repo
Whereas buildiso creates a bunch of sfs overlay filesystems - put them together with a bootloader and packing them into an iso image. Later Calamares simply unpack two of these filesystems onto the target namely the root filesystem → then the desktop filesystem.
If you want to customize further you the do so in several ways.
The simplest way is by adding files and folders to the desktop-overlay in the profiles folder.
The second method can be achieved by altering the content of the raw filesystems stored in /var/lib/manjaro-tools/iso/.
To access the folders before ISO creation you would use the -x argument with buildiso.
Then add or change content in the filesystem folders and finalize the build using the -zc arguments to with buildiso.
When knowing all this it is possible to alter and customize the final ISO in every possible way and maybe some you haven’t thought of yet.
Pseudo script modifying the prebuild images with custom build AUR package
The .pacnew is one reliable, consistent way, or at least I thought it was.
