Today I updated my system and got two pacnews(one for /etc/pacman.conf and another for /etc/makepkg.conf.d/fortran.conf). I was able to get through the pacman.conf pacnew but i have no idea what to do for the other one.
here is the pacnew and the file on my system
[cc@computer ~]$ cat /etc/makepkg.conf.d/fortran.conf.pacnew
#!/hint/bash
shellcheck disable=2034
/etc/makepkg.conf.d/fortran.conf
#########################################################################
FORTRAN LANGUAGE SUPPORT
#########################################################################
Flags used for the Fortran compiler, similar in spirit to CFLAGS. Read
linkman:gfortran[1] for more details on the available flags.
FFLAGS=“-march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-Wp,-D_FORTIFY_SOURCE=3 -fstack-clash-protection -fcf-protection
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer”
FCFLAGS=“$FFLAGS”
Additional compiler flags appended to FFLAGS and FCFLAGS for use in debugging. Usually
this would include: ``-g’'. Read linkman:gfortran[1] for more details on the wide
variety of compiler flags available.
DEBUG_FFLAGS=“-g”
[cc@computer ~]$ cat /etc/makepkg.conf.d/fortran.conf
#!/hint/bash
/etc/makepkg.conf.d/fortran.conf
#########################################################################
FORTRAN LANGUAGE SUPPORT
#########################################################################
Flags used for the Fortran compiler, similar in spirit to CFLAGS. Read
linkman:gfortran[1] for more details on the available flags.
#FFLAGS=“-O2 -pipe”
#FCFLAGS=“$FFLAGS”
Additional compiler flags appended to FFLAGS and FCFLAGS for use in debugging. Usually
this would include: ``-g’'. Read linkman:gfortran[1] for more details on the wide
variety of compiler flags available.
#DEBUG_FFLAGS=“-g”
here is my /etc/pacman/conf (i added the #DisableSandboxFilesystem and #DisableSandboxSyscalls options and saved the file:
[cc@computer ~]$ cat /etc/pacman.conf
/etc/pacman.conf
See the pacman.conf(5) manpage for option and repository directives
GENERAL OPTIONS
[options]
The following paths are commented out with their default values listed.
If you wish to use different paths, uncomment and update the paths.
#RootDir = /
#DBPath = /var/lib/pacman/
#CacheDir = /var/cache/pacman/pkg/
#LogFile = /var/log/pacman.log
#GPGDir = /etc/pacman.d/gnupg/
#HookDir = /etc/pacman.d/hooks/
HoldPkg = pacman glibc
#XferCommand = /usr/bin/curl -L -C - -f -o %o %u
#XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
#CleanMethod = KeepInstalled
#UseDelta = 0.7
Architecture = auto
Pacman won’t upgrade packages listed in IgnorePkg and members of IgnoreGroup
#IgnorePkg =
#IgnoreGroup =
#NoUpgrade =
#NoExtract =
Misc options
#UseSyslog
Color
ILoveCandy
#NoProgressBar
CheckSpace
VerbosePkgLists
DisableDownloadTimeout
ParallelDownloads = 5
DownloadUser = alpm
#DisableSandboxFilesystem
#DisableSandboxSyscalls
By default, pacman accepts packages signed by keys that its local keyring
trusts (see pacman-key and its man page), as well as unsigned packages.
SigLevel = Required DatabaseOptional
LocalFileSigLevel = Optional
#RemoteFileSigLevel = Required
NOTE: You must run pacman-key --init before first using pacman; the local
keyring can then be populated with the keys of all official Arch Linux
packagers with pacman-key --populate archlinux.
REPOSITORIES
- can be defined here or included from another file
- pacman will search repositories in the order defined here
- local/custom mirrors can be added here or in separate files
- repositories listed first will take precedence when packages
have identical names, regardless of version number
- URLs will have $repo replaced by the name of the current repo
- URLs will have $arch replaced by the name of the architecture
Repository entries are of the format:
[repo-name]
Server = ServerName
Include = IncludePath
The header [repo-name] is crucial - it must be present and
uncommented to enable the repo.
The testing repositories are disabled by default. To enable, uncomment the
repo name header and Include lines. You can add preferred servers immediately
after the header, and they will be used before the default mirrors.
[endeavouros]
SigLevel = PackageRequired
Include = /etc/pacman.d/endeavouros-mirrorlist
#[core-testing]
#Include = /etc/pacman.d/mirrorlist
[core]
Include = /etc/pacman.d/mirrorlist
#[extra-testing]
#Include = /etc/pacman.d/mirrorlist
[extra]
Include = /etc/pacman.d/mirrorlist
If you want to run 32 bit applications on your x86_64 system,
enable the multilib repositories as required here.
#[multilib-testing]
#Include = /etc/pacman.d/mirrorlist
[multilib]
Include = /etc/pacman.d/mirrorlist
An example of a custom package repository. See the pacman manpage for
tips on creating your own repositories.
#[custom]
#SigLevel = Optional TrustAll
#Server = file:///home/custompkgs
There is no need for you to intervene, just to understand the principle why .pacnew files are being used, just check this explanation.
In short, the same principle of using '.pacnew files, instead of modifying the actual source file, is being used when you’re ranking your mirrorlists. Within the path /etc/pacman.d/ you may find endeavouros-mirrorlist as well as a more recent endeavouros-mirrorlist.pacnew file. Which is totally fine.
Today I updated my system and I did not get this pacnew files , as a matter of fact (if my memory service me right) it was some time ago that I got the pacman.conf pacnew file. So that makes me wonder how often do you update ?
There must be something wrong with my system because I just did another update and no pacnew files appeared, oh dear oh dear , what am I going to do now
That is exactly what I meant to say, because the last one I got was from 30 november and it was a eos mirror pacnew file, was just fooling around a bit
waarschuwing:/etc/makepkg.conf is geïnstalleerd als /etc/makepkg.conf.pacnew
waarschuwing:/etc/pacman.conf is geïnstalleerd als /etc/pacman.conf.pacnew
After adding the update(s) to pacman.conf and makepkg.conf i get this error in yay
That is not adding a update that is overwriting the two files with the pacnew files which you never should do unless you now that it is alright to do so.
Every once in a while I do a check on the pacnew files. some of them contain new default config options which I no not know about yet. New comments, corrected typos etc. are also frequently included in pacnew files.
The easiest way for me to compare pacnew with what I have in my config is with the tool meld.
it opens a GUI with both files side by side and it is very easy to move changes between the files. This way I keep my legacy config files up to date. After this exercise I delete the pacnew file.
PS
I find meld also very useful when it comes to comparing directories with many text files.
I got three pacnew files when updating my system some minutes ago. I added these two lines into my etc/pacnew.conf.
#DisableSandboxFilesystem
#DisableSandboxSyscalls
But they are not enabled, so I didn’t have to add them. All other lines I left as they were.
/etc/makepkg.conf and /etc/makepkg.conf.d/fortran.conf I overwrote with the pacnew files, because it looked like there were no changes from EndeavourOS Team and I also didn’t change anything in the old files.
If you reverted them you will build debug packages, enable autodeps ,… resulting in slower builds overall.
You should also make sure to include multilib inside pacman.conf .
[multilib] Include = /etc/pacman.d/mirrorlist
@anon543456
When it comes the configuration changes, to the fortran compiler I cannot answer this. Here the eos-team made some small changes. The pacnew would introduce a bunch of compiler flags and possibly change behaviour.
I currently don’t know to what extent fortran is needed or which packages are linked against libgfortran.
My quick superficial search on my machine only found cmake.
Yes the problem with these pacnew files is they often are based on vanilla arch, and don’t contain any changes made by the eos developers. A (in) famous example was the pacnew file that didn’t contain any referal towards the eos repo, and some forum members got into trouble by overwriting the original pacman.conf file with a pacnew file, because they could not update the eos repo as a result.
That’s what I did. That’s why I only added 2 new lines into the pacman.conf.
Ok … That’s bad … Thanks for the link to the EOS makepkg.conf file. I overwrote my one with the linked one. That should be fine, I think. Right?
But there was another change in /etc/makepkg.conf.d/fortran.conf. How can I get that back to the EOS one?
Does that mean, that no matter if there are pacnew files, I shouldn’t overwrite my ones? How do I know that there are changes in them that must be changed??
But there was another change in /etc/makepkg.conf.d/fortran.conf. How can I get that back to the EOS one?
This is the old file. But as I wrote previously, I don’t know enough about fortran on arch. So I do not know what to override and what not.
When it comes the configuration changes, to the fortran compiler I cannot answer this. Here the eos-team made some small changes. The pacnew would introduce a bunch of compiler flags and possibly change behaviour.
I currently don’t know to what extent fortran is needed or which packages are linked against libgfortran.
#!/hint/bash
#
# /etc/makepkg.conf.d/fortran.conf
#
#########################################################################
# FORTRAN LANGUAGE SUPPORT
#########################################################################
# Flags used for the Fortran compiler, similar in spirit to CFLAGS. Read
# linkman:gfortran[1] for more details on the available flags.
#FFLAGS="-O2 -pipe"
#FCFLAGS="$FFLAGS"
# Additional compiler flags appended to `FFLAGS` and `FCFLAGS` for use in debugging. Usually
# this would include: ``-g''. Read linkman:gfortran[1] for more details on the wide
# variety of compiler flags available.
#DEBUG_FFLAGS="-g"
Does that mean, that no matter if there are pacnew files, I shouldn’t overwrite my ones? How do I know that there are changes in them that must be changed??
No, it doesn’t. With time comes experience, and you’ll learn through understanding what to override and what not.
the thing with .pacnew files is that they are “updated with new or other options”. As you are in charge as system operator you can deside if you accept those changes or not.
With commando diff original file pacnew file you can deside for yourself if you overwrite the original but imho personally i never change because in some files i change options myself. Those options which you make yourself are never in the .pacnew files so …
But if you do make sure you always have a copy of the original.
The simple main rule with .pacnew files is: Never overwrite if you don’t know exactly what you are doing!
This can’t be stressed enough!
Some background:
Most of the .pacnew files come from Arch, not from EndeavourOS.
Many EndeavourOS related .pacnew file names start with eos- but not all.
Some .pacnew files are not meant to overwrite existing config file!
For example:
/etc/passwd
/etc/group
/etc/shadow
and a few others.
Many .pacnew files contain new or fixed features for the related app or apps. They are good candidates to be carefullymerged (not blindly overwrite!) with the existing config file.
Example: /etc/eos-rankmirrors.conf.pacnew
Some .pacnew files are meant to replace the existing config file.
Example: /etc/pacman.d/endeavouros-mirrorlist.pacnew
Possibly there are other meanings for the .pacnew files, since they bring something new and often interesting. But the main rule above still holds.
And about the makepkg.conf and fortran.conf files: they are mainly for developers, but also other users may need the contents of makepkg.conf e.g. when using yay to build and install a package.
For example, in makepkg.conf there is the OPTIONS variable and it contains option debug which causes also building a debug package. Typically the debug package is not needed by non-developers, so the option can be disabled by adding a ‘!’ character in front of the option name.
This .pacnew thing has made me a little unsure whether Arch Linux / EndeavourOS is actually the right OS for me. I find it difficult to decide which changes can be overwritten / adopted without any problems and which cannot. That’s why I’ve been using Fedora 43 for a few days now. There are no such .pacnew things here.
But now that I’m browsing the community again, I’m starting to feel at home, and I’m curious. It’s a difficult decision that’s been on my mind for days: EndeavourOS yes or no. Actually, I’ve always been very happy with EndeavourOS. But there are a few issues that confuse me when they arise …
When ever I find something a bit difficult to grasp I have this saying I use to keep me out of trouble “When in Doubt Do without”. I may loose a new feature but I won’t loose my already working the way I want system.
At the end of the day you have to do whats best for YOUR computer experience. I very much believe in using the tools that work to get the job done. Why use a wrench to drive a nail
And as far as the community goes. We have members who don’t use EndeavourOS so no need to go anywhere just because you choose another OS.
If there are questions about how to deal with some feature, please do no hesitate to ask here! I’m sure you’ll get great answers. This is what this forum is about too.
And there may be other users with the same question in mind, so they will also benefit.
