Is the delta option in pacman.conf currently operational?

Hey Folks,
I noticed that there is a delta option in pacman.conf that is commented by default. What is the status of this function? Is it currently safe to use?
Cheers,
Scott

Well, it is safe to use but the Arch repos do not provide package deltas so there is not benefit yet...

Similar Messages

Cannot see the delta option in update tab for info package

Hi,
I need to create 3 info packages for a data source.
When I right click and pick create infopackage and go to the update tab to choose delta, I see only full and initialize...
Can someone let me know why, and what should I do to see the delta option for my infopackage.
Thanks

hello radha
oka pani cheyyi....
I mean you may try this following procedure for this error.
Search the init IP
1.     Double click in the IP
2.     Scheduler menu
3.     Click in Initialization options for source system
Select and delete the only entry ( INIT) .
Now go to Source systems -
> right click your source system----> replicate.
Activate your transfer rules, using program RS_TRANSTRU_ACTIVATE_ALL
now try to perform Init again.
It will work.
Cheers!!!!

Has Pacman3 dropped support for the NoUpgrade Lines in pacman.conf?

I just upgraded to Pacman 3. When I upgraded I quickly saw some output on my sceen saying it was doing a one time "reset" and I believe it said I could delete the NoUpgrade lines in pacman.conf.
I noticed that pacman.conf.pacnew does not have any NoUpgrade lines.
Should I delete all the NoUpgrade lines from my pacman.conf file?
Is the NoUpgrade line no longer supported in pacman3?
If so, how can I protect some of my config files from being overwritten during upgrades?
Rob

They're still supported, there just aren't any by default anymore. They were redundant.
You can/should remove any that are listed in the "backup" list for the packages they come from (pacman -Qii package). Those are all handled as if they were in NoUpgrade anyway.

/etc/pacman.conf question..

This may have been asked before, but I could not find it...
<yes, I did use the search on the forums... >
I was wondering if the NoUpgrade option in pacman.conf uses shell-like wildcard expansion...
Does the following work?
NoUpgrade = etc/host*
shell expansion should expand this to
/etc/host.conf
/etc/hosts
/etc/hosts.allow
/ec/hosts.deny
will pacman do the same?

No, but it would be nice to have something like that (or perhaps better with regexp)
BTW, regexp support for targets was already in pacman wishlist.
I've added noupgrade/ignorepkg options to it.
To be continued...

Request for a "NeverUpgrade" option for pacman.

Yesterday something very serious happened, pacman moved my grub menu.lst file to menu.lst.pacsave. If I wouldn't have spotted this, my system would have become unbootable. This can be fixed by putting it in NoUpgrade (pacman.conf) by default, but there is an underlying problem here.
Pacman will always move your modified files (excluding the ones in NoUpgrade) to .pacsave and use a default file instead. Imagine this would happen on the httpd.conf (apache), my.cnf (mysql), php.ini (php),... files on a production server! It shouldn't, the server admin should have seen that pacman moved them, or he should have put them in the NoUpgrade line. But we're all human and these things happen. And a human error like this already happened with the grub file.
I've always been concerned with the actions of pacman. As Gyroplast said on irc: "Don't f*cking touch any already exiting config files until I explicitly tell you to!".
I've also noticed that a lot of times, these 'new' files are just the same as the original (unmodified) file, or are not worth the upgrade. It only costs time moving the old file back to its original position.
Newbies, people who didn't see that pacman moved their old file (on big updates, the console can even be to small to show this), people that do a "pacman -Syu" through cron,.. will never notice that their system can become unbootable, that apache's config file has been moved, so all their client's sites will be down after a reboot or apache restart,...
This is a very serious issue!
I have a very simpel solution though. I'm sure there are some people that are used to the old way and want to keep it, so we should give people the choice. Either use the old system, or the new. Let's say there is a "NeverUpdate" = yes/no option in pacman.conf. (default: YES!)
If you say no, everything will be back to 'normal'.
If you say yes, things will be different. We will now work with a whitelist instead of a blacklist as Gyroplast proposed. So instead of the "NoUpgrade" option, we will have an "Upgrade" option. All files will be protected by default (and use the .pacnew system), only the files in "Upgrade" can be overwritten, and moved to a .pacsave version. This is all VERY easy (and fast) to implement, if I knew C I would do it myself
I think it's important that this happens as soon as possible, to prevent things like the grub fiasco to happen again.
We can go further however: when a packager creates a new package with config files, he can tell pacman what has been changed (with a new option in PKGBUILD). If I upgrade that package, pacman will tell me exactly what has been added/changed so I can upgrade my file really quickly. Much faster than doing a 'diff' or just comparing it line by line. More work for 1 packager, but less work for hundreds of users. (and that 1 packager will also benefit from this, because he will save time updating packages from other packagers, so a win-win situation 8)). I realize that this will be much more work to implement, but would be a very nice feature in some future version of pacman.
I'm sure there will be some discussion about this, new ideas, people that hate me,..
I hope the Arch developers (particulary apeiro) will join this discussion, and also explain to us why the current pacman is so radical.

FreeBSDs mergemaster really only is a frontend for sdiff, no black magic, so it'd probably be well possible to port it to arch, especially as it's only a shell script.
I think I've given enough examples of how someone can miss this
Yeah, and I could easily construct a dozen more, but there's no excuse for not paying attention to the output of a crucial program if you cannot risk your system going haywire. If you _can_ risk it, though, your point is moot.
The inherent problem is that you cannot fully automate the process, thus always requiring manual interaction if a new config file differs from the original file and the current file has been modified. There is no way around that. You will shredder your system if you do not pay attention when this scenario happens, with the proposed change a little less often, but still. Since problems are not totally ruled out, you still have to check just as often as before, because you cannot know in advance how basic the config file changes are. If you still have to do the same amount of work, I don't see a reason to change anything.
I do not believe in "some security". Either pacman is able to do the job of upgrading reliably and automatically, or it is my sole duty to ensure configuration integrity. All pacman has to (and already can) do in that case is telling me that my interaction is required, and where. It does that now already (if I leave the NoUpgrade misbehaviour aside).
The mergemaster tool would be a very helpful _additional_ tool that could be offered, I have nothing against that, but it's not part of pacman. As I wrote it's just a frontend to sdiff, a fancy tool that may or may not be used. One job - one tool. Pacman's job is installing packages, not solving impossible dilemmas, therefore I'd vote against this extra functionality and would rather discuss how to improve administrator notification to reduce the chance of changes going unnoticed.
A solution to this underlying core problem would be "statistics" at the end of an upgrade process, stating if and what files have been replaced with newer versions. That's legible, it's easy to implement, and it does the job. If you're running pacman unattended, you're acting irresponsible. No matter if your config is replaced or not, you risk your system's integrity, the former risks it a bit more, the latter a bit less, but it's nevertheless risked, which is per se inacceptable, thus leaving the difference in reliability being merely a moot point.
I'll rephrase that:
Yes, the system will probably break more often if the current implementation is kept, but only if the administrator does not do his job and check pacman's warnings. There are no superfluous warnings being generated by pacman that would cause an admin to disregard the output, the only (documented) case of a pacsave being generated is when default config parameters have been changed in the package, which needs interaction _every time_. You're not winning anything by the change, you just gain a "safety net" that is not sufficient for the situation you are constantly referring to; A server system that simply must work. Therefore the safety measure is useless by concept. You cannot reliably help an admin who does not care, and if an admin does not care, it's by defintion not important enough to be considered, so why should a function be implemented that would solve (some, but not all) cases that are considered as unimportant by the admin anyway?
Whoa, evil topic here, so I say "Port mergemaster, make pacman a bit more verbose, be done with it." to keep it short.
Greets,
Dennis

Hi accidentally overwrote new pacman.conf with /etc/pacman.conf.pacnew

Hi
I accidentally overwrote etc/pacman.conf with the old /etc/pacman.conf.pacnew.
Pacman now appears to work but disregards the signing of packages.
Is there an copy of the pacman.conf from the upgrade around so I can merge
the two files. perhaps pacman.conf~, but no I think this is overwritten too.
Regardz
El Zorro

Hi Trilby,
it may be the mouldy oldy one as there is no reference to "SigLevel = Never" it does not seem to exist only "Architecture = auto"
Here is the current /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
HoldPkg = pacman glibc
# If upgrades are available for these packages they will be asked for first
SyncFirst = pacman
#XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
#XferCommand = /usr/bin/curl -C - -f %u > %o
#CleanMethod = KeepInstalled
Architecture = auto
# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
#IgnorePkg =
#IgnoreGroup =
#NoUpgrade =
#NoExtract =
# Misc options (all disabled by default)
#UseSyslog
#ShowSize
#UseDelta
#TotalDownload
#CheckSpace
# 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.
#[testing]
#Include = /etc/pacman.d/mirrorlist
[core]
Include = /etc/pacman.d/mirrorlist
[extra]
Include = /etc/pacman.d/mirrorlist
#[community-testing]
#Include = /etc/pacman.d/mirrorlist
[community]
Include = /etc/pacman.d/mirrorlist
# An example of a custom package repository. See the pacman manpage for
# tips on creating your own repositories.
#[custom]
#Server = file:///home/custompkgs
Trilby wrote:
The pacnew version includes everything for package signing. All you will have lost is any personal changes you have made.
The package signing lines are, however, commented out except for the "SigLevel = Never" line. Just read the instructions within the comments and uncomment the appropriate SigLevel line (and comment the "Never" line).
Last edited by elzorro (2012-01-21 06:31:50)

[SOLVED] Is there a way to disable the 10s timeout in pacman?

I keep hitting this timeout because of some silly corporate network shenanigans. However, if I manually download the file from the mirror then it (eventually) completes. I don't mind typing 'pacman -Syu' and then waiting a few extra minutes for the update to go through. I just hate having to manually download each file.
Could this maybe be an option in pacman.conf?
Last edited by nathanb (2012-11-06 23:23:25)

You could use wget or something like this with pacman. Just look into the manpages or .conf file. I do this when I'm in my coorporate network because of proxy servers.

Pacman.conf NEED tips for totally offline install with DVD repository

OBJECTIVE: after a base install with ARCHBOOT be able to install from DVD repository which contains repo-add database.
My DVD contains the folder from /var/cache/pacman/pkg.
ON the DVD I have the folder 'pkg' at the dvd root level and another folder which has my already built packages fro AUR.
The database called 'custom.db.tar.gz' created with repo-add exists IN the pkg folder on the DVD.
The built AUR packages are in a seperate folder called '_built' at the dvd's root level as well and they are not included in the repo-add database.
I am able to mount the dvd, cd to the pkg folder and use pacman -Ud to install them though this requires that I type in the full name of the package and I get dependence issues and '*.so' type files not found.
IF I copy all the files from the DVD to the var/cache/pacman/pkg folder I am able to add my local repository to pacman.conf and MUCH more efficient install. I can use pacman -S xorg for example, and I think it finds dependencies even. Can't recall exactly at the moment.
SO: do I need to alter pacman.conf cache location line and the other lines?
Would I change the 2nd and 3rd lines to get max pacman ability when using DVD repository???
Pointing them to my DVD folder after mounting the dvd
#RootDir = /
#DBPath = /var/lib/pacman/
#CacheDir = /var/cache/pacman/pkg/
#LogFile = /var/log/pacman.log
I really would like to have as much power and flexibility when using the DVD as the repo.
Can anyone tell me what I should alter in pacman.conf for this.
I am fine if I have to alter the cache location line temporarily if it will give me additional pacman ability.
I have read all the wiki stuff for sure though I'm still a bit in the dark and wanted to ask without typing the many many options.
One big one for me is I don't yet know how to set the SERVER = in pacman.com to look at the mounted DVD and the pkg folder specifically.
I do mount /dev/sr0 /mnt/cdrom
So what would I put as the SERVER for this in pacman.conf
SERVER = /dev/sr0 ????? or /dev/cdrom ???? or /mnt/cdrom I think ????
dunno!
AND I really probably DO have to temporarily alter the pacman.conf cache location line to get pacman to do dependency installs and let me type short lines instead of the full package name.
THANKS! this one is BIG for me!!!!! :---)
Last edited by yvonney (2009-06-18 20:27:14)

COMMENT WRITTEN LAST: I was about to delete a lot of stuff here though thought to just say sorry for not taking the brain-time to slim it. The bold and white boxed part is the main related quest-ion.
you might find a few useful tools on my site (in my sig), e.g. pkgd if you want to save bandwidth on a LAN --- pbget if you want to easily get PKGBUILDs etc from the AUR and official repos, etc.
WOW Xyne !!!! thanks. pbget etc. sound very cool.
I used yaourt until very recently. Then went ....hmmmm... should learn about manual building and local repo. Where I'm at now is trying to do as much manually as possible. I think I kinda know what packages I want and there will only be some changes from that in the future. There's maybe 20 packages from AUR for me. [PLUS their dependencies]
Of course: I am doing the repo-add local repositories thing for speed, learning, and as part of my whole 'best practices' growth. Plus it will come in very handy when helping other decide quickly if a barbones mainly wm/ncurses lightweight system is for them.
You certainly spark a question or two!
[AUR and dependencies via yaourt affecting my plans to now go manually]
As these have all ALREADY been installed via yaourt my BIG concern is that I've never found much of a yaourt/cache folder. You see, as you'd know many many times upon installing vai yaourt there's some dependency that may, or I guess, may not be in the standard repos.
After installing these packages via yaourt do the dependencies go into /var/cache/pacman.pkg and is pacman aware of it when I do a repo-add for thecustom database. If so, then all if fairly cool for my plans. I bet there's a few idiosyncrasies about AUR and dependencies maybe.
-AUR dependency resolution-
Using a custom repo will not really work for general use because you would need to manually populate the database with the dependencies anyway.
I'm fine with manually doing dependencies - though need to know if my yaourt usage ALREADY put the latest dependencies in the pacman cache for AUR unsupported packages AND is there a way with the whole repo-add, local repositry, pacman and aur concpt I'm planning to fine tune to have the dependencies update when I go back to the online repositries? I don't think so based on my usage with yaourt, though can't quite recall.
As I will be enjoying makepkg building the group of packages I nee to get from AUR for the forseeable future (that are not in the main 3 repos of course)
I'm still wondering about the inter-relationships. So: I already have installed and/or built the packages for everything I expect to need mostly. I never became beyone mediocre with yaourt. and that fine, though I now have to consider that in a new install I DO have the latest AUR built packages, though will there be the right dependencies ALREADY in my /var/cache/pacman/pkg ?
There's a few things that I'd love to really understand about this. Even if it ends up that dependencies for the AUR packages is always a bit trickier.
QUESTION: right now I am uable to try custom repo from flash stick as it's read only. I'll be googling this one out and am really looking forward to having a flash stick with ARCHBOOT and I gues ONE repo pkg folder and database on it.
NOTE: I will put the custom repo above the stock ones in pacman.conf. I just commented out the others as I was doing all this offline.
I've dumped the dvd as a repo and have switched to a flash stick. I've extracted the archboot out to a 4 gig flash stick.
dd if=/root/Desktop/archlinux-2009.05-2-archboot.iso of=/dev/sdb Its read-only at the moment and no matter what I've tried it stays that way. Maybe I need to use the HPutil on it. It definitely isn't writeable so I won't ponder or note observations here save to say that 'm stumped as to how to get files copied to it.
And now what may be the way I'd like to work: Keep my folder for building packages from aur which is /root/aur. Then after doing the fun makepkg --asroot or even makepg -i as root to install. Though I'll probably after the build THEN just copy the built packages from my /root/aur to /var/cache/pacman/pkg and install from there as I DO plan to use the online repos.
I will ALSO copy the file to my USB stick or maybe just sync to it and do a the repo-add thing in /var/cache/pacman/pkg and keep the stick as both backup and 'in the ready' reinstaller.
Um, now could spend an hour editing down the above!!!
wondrous thanks!
Last edited by yvonney (2009-06-19 07:38:25)

DELUGE_USER option in /etc/conf.d/deluged and deluge v1.3.4-2

I did an upgrade to deluge v1.3.4-2 today and in that version it seems that the DELUGE_USER option in /etc/conf.d/deluged isnt used anymore. Is that the case?
If thats the case then how do run deluge as another user?
Im following this bug:
https://bugs.archlinux.org/task/28847

Same situation here...
User deluge has been hardcoded into the initscript, changing the user deluge both in deluged and deluge-web script restore the wanted behaviour....
As per the error messages of kill, they are generate because the mainteinar changed the behaviour of the script.
Before the update, the stop section removed the pid from /run/deluge
Now the script does not remove the pid file, it tries to overwrite the pid value inside with the new value.
But still this section puzzles me:
PIDFILE=/run/deluge/deluged.pid
OPTIONS="-P $PIDFILE $OPTIONS"
[[ -f $PIDFILE ]] && PID=$(<$PIDFILE)
kill -0 $PID || PID=
Because:
- Why test if the pidfile is a regular file? (-f flag)...imho sure that it is, no one touch it except for deluged main program and now that the script has been modified the file is not removed and recreated anymore during any operation
- Why always try to kill the process?? That brings the error message of kills in two situations: when the program is first started and deluged.pid does not exists, and during restart operation, where kill cannot find the process since in the pidfile there is still the old pid value and the process has been killed by this section during the stop operation. Imho the kill should be performed in the stop section and not in the header. Or delete the pidfile during stop operation, and check for the existance of file before grabbing the pid value and kill it. What's the behaviour of the new version of deluged when you pass as an argument the pidfile? It creates the file if does not exists or requires that the file exists?

Delta options

hi experts,
I have a doubt in deltas.wht r the delta options available for the infocubes and ods?
regards,
kumar.

Hi,
For both cubes and ODS the delta options are the same. i.e you need to initialize the delta before you can set up the delta. In initialization again there are 2 options, Init with data transfer (this acts as a full load and also initializes the delta) and the other one is without data transfer (no data just initialize).
After this is done, the delta radio button apprears on the infopackage. You can use the same infopackage you used for initialization, but best practice is to create a new one for the delta. After this, you would be able to see the delta entries in the delta queue RSA7 on the source side.
Cheers,
Kedar

[SOLVED] pacman.conf simple line error or... ?

So here's what happened:
I was trying to enable the [multilib] repository. (As according to https://wiki.archlinux.org/index.php/Multilib).
Thus, I went ahead and uncommented the following from /etc/pacman.conf:
[multilib]
SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist
To edit /etc/pacman.conf, I used LibreOffice Writer. I saved the file as a .txt document and made sure that it is properly renamed as pacman.conf.
Next, I went to update pacman's package list by running pacman with the -Sy switch.
And then, voila:
# pacman -Sy
error: config file /etc/pacman.conf, line 1: All directives must belong to a section.
However, when looking at pacman.conf I don't see any errors in line 1. Nor do I see any problems with directives.
Here are the contents of pacman.conf:
http://pastebin.com/raw.php?i=XWh9eagr
Is there a simple problem with a line in pacman.conf --- or is it because I used LibreOffice Writer instead of Vi? Or?
Is the answer to this right in front of my nose?
Thank ya'll..
Last edited by adamstjohn (2012-12-08 00:31:28)

adamstjohn wrote:or is it because I used LibreOffice Writer instead of Vi?.
LibreOffice Writer is a word processor - it will do odd things to your .conf files. Use a text editor. If you don't want to use vi, then use nano, or gedit or anything other than a word processor.
Moving to NC: not at all related to pacman...

Pacman.conf.pacsave etc?

I recently upgraded my system to the newer packages and I noticed some messages when I did this. The pacman.conf.save as well as rc.local.pacsave and a few others were listed as being created. What wasn't clear was what I am supposed to do with these multiple files.
I noticed that the pacman.conf file was actually different than my original as the IGNOREPKG line was commented whereas I had mine commented out.
So, can this be clarified? Perhaps even a list of the files that typically get replaced and what users are supposed to do with them.
Thanks in advance.

Anything with a .pacsave extension is a configuration file that has been backed up. Your previous pacman.conf file was moved to /etc/pacman.conf.pacsave and the new file from the new package was placed in as /etc/pacman.conf.
To prevent that from happening, add etc/pacman.conf to one of the NoUpgrade lines in pacman.conf. Then the next time pacman is upgraded, your original config will be preserved and the new file will be saved as /etc/pacman.conf.pacnew.

Edit pacman.conf without editor

Hi folks,
I have got a BIG problem. That is what I did:
I installed a new /etc/pacman.d/mirrorlist
after that I got an error in pacman, which said that the architecture is unknown or sth
so I inserted "Architecture = x86_64" into pacman.conf and did some updates
after a restart some time later xinit failed to initialize "x" ... probably because my window manager can not load (see following text)
well, now I am left without X and when I try to start vim it says sth like: "error while loading shared libraries gtk-x11-...sth... wrong ELF class ELFCLASS64"
now I tried to install nano via pacman which was successful, but as soon as I try to start nano it says "/usr/bin/nano file or directory not found" (I also tried to install vi with the same result)
Now I am really lost since I can not edit any files, especially pacman.conf to change the architecture, since I guess the origin of my problem is that I did not have a x64 system in first place!? Even though I am sure I have ...
Do you have any idea how to fix my system? I can still use pacman and mount a usb device, if that helps?
Best,
Tobias

Please try to give us some more information:
Do
ls -l /usr/bin | grep nano
and see if nano is actually present. Also check if "/usr" is mounted
mount
. If you are unsure, post the output.
Also please provide your pacman.conf so we can see if there's anything wrong there. To get it do
cat /etc/pacman.conf
. Then place it in the file as noted below.
Note: to provide the output do the following:
COMMAND > ~/command_output.txt
. Then you can copy those files to a usb drive via
cp ~/command_output.txt /path/to/usb
This could help us figure out the problem.
You could also look into tools for "editing" a file in the command line. Maybe 'sed' can help there, not so sure myself. Perhaps you can do some kind of
cat /etc/pacman.conf | *command to replace/remove the Architecture line* > /etc/pacman.conf
Watch out though, ALWAYS make backups, you don't want to screw things up even more.
Hope this helps.
By the way: You change doesn't look so wrong if I am not mistaken. I wonder how this could screw things up this way?
Oh by the way: If all else fails, boot a live cd, mount your system and edit the files via live cd tools. If you then want to test things you can chroot into your mounted system.

Yaourt (0.9.4-2) (aur) ignores IgnorePkg rules in /etc/pacman.conf

Usually doing yaourt -Syu --aur goes through and updates all of the packages I installed from aur unless the package is among those listed in the IgnorePkg array in pacman.conf. However, the recently updated yaourt from aur simply ignores the rule and prompts me to upgrade the package anyways. For example, I see this for bin32-wine.

opened a bug report:
http://bugs.archlinux.fr/task/170

When i open itunes it gives me the option to download the new version 10.3. my computer will not support 10.3. i can't by pass the download to continue with my current version of itunes. i've trashed and reinstalled 8.2.1 twice. any solutions?

When i open itunes it gives me the option to download the new version 10.3. my computer will not support 10.3. i can't by pass the download to continue with my current version of itunes. i've trashed and reinstalled 8.2.1 twice. any solutions?

I am in the same boat. I tried repeatedly to contact iTunes support, but was told each time that I had contacted the wrong deaprtment and they could not help me. There must be a way to still be able to use the iTunes store without paying for a system update. If not, I hope they will reimburse me the money I have in my acount.

Is the delta option in pacman.conf currently operational?

Similar Messages

Maybe you are looking for