You are not logged in.
I think what people want is a simple answer to a simple question. I found a link
http://forums.scotsnewsletter.com/index … opic=49584
that gives this suggestion:
# cp /etc/profile.d/locale.sh /etc/profile.d/locale.sh.backup && rm /etc/profile.d/locale.sh
Offline
# cp /etc/profile.d/locale.sh /etc/profile.d/locale.sh.backup && rm /etc/profile.d/locale.sh
This is SOP to me, instead of removing stuff I comment it out or move it somewhere.
I think Archers are expected to know that.
Offline
@kraxor: +1
Is that a joke ... Here is my error :
(314/314) checking for file conflicts [################################################################] 100%
error: failed to commit transaction (conflicting files)
initscripts: /etc/profile.d/locale.sh exists in filesystem
Errors occurred, no packages were upgraded.
... and then, the Linux administrator system I am is stuck and should google to unlock this situation ... This is very NOT good for Arch Linux. Check out how Gentoo works with news : it's beter and you will see what to do IN THE CONSOLE without having to search on google ...
Seriously, I've not time to lose by pre-checking possible error using forum or anything else ; you have to integrate a news system into pacman or people like me will be bored and may leave this distrubution ... Hope you understand ..
If a package manager exists, it MUST do the whole work without complaining to the users for some stupid things. Hope this will be fixed for new cases .
Last edited by loopx (2011-11-13 14:25:28)
Offline
@loopx,
to cite our Pacman Wiki: "this is a design feature, not a flaw".
I really do not want to have pacman messing with any of my system setups. And in most cases the solution is trivial: Delete the offending file, or rename it, or move it out of the way. Then try again.
To know or not to know ...
... the questions remain forever.
Offline
@loopx,
to cite our Pacman Wiki: "this is a design feature, not a flaw".
I really do not want to have pacman messing with any of my system setups. And in most cases the solution is trivial: Delete the offending file, or rename it, or move it out of the way. Then try again.
I think loopx has issue with the information being scattered in various places, not with how pacman behaved in this particular situation.
Offline
Seriously, I've not time to lose by pre-checking possible error using forum or anything else ; you have to integrate a news system into pacman or people like me will be bored and may leave this distrubution ... Hope you understand ..
CALLING ALL PACMAN DEVELOPERS NOW
Offline
Pacman knows the file must be moved out ... so why isn't it capable to inform the administrator ? It should, and this is a feature to add to the TODO list
Offline
Here is what Pacman can (already) do for MediaWiki :
(1/1) upgrading mediawiki [################################################################] 100%
-- Don't forget to run 'php maintenance/update.php' after upgrade
-- Mediawiki is in /usr/share/webapps now
... you should do the same for initscripts ... but before install
Offline
By the time install scripts are run, file conflict checking has already been performed and the package is going to be installed. It's too late in the process. Your mediawiki example is a crock of shit because it's not nearly the same.
you should read the news -- RSS is a wonderful thing and we provide it. you should be responsible and understand that pacman will not, nor will it ever, move system files around like this.
Frankly, Arch isn't out to win some imaginary race. If we lose users like you because they're "bored" or whatever, then I'd say Arch actually wins.
Offline
You are really not serious. I can't read all new using RSS or anything else for :
- Arch
- Gentoo
- Red Hat
- Ubuntu
and what else ? And if I don't do the upgrade regularly, I will forget this new and ... and the problem is still the same as before : should simply print in the console to inform the administrator ...
I simply need more information in the command line ...
Do you know what was the worse in this story ? I never wanted to upgrade my system ... But, since I installed Quagga (for dynamic routing protocols OSPF) .. which has required "AUR" which must be manually installed (...) .. these last packages has broken some library for Cupsd (and other?) and thus, .. cups was broken (can't open dynamic library ...) .. Ok, I do the upgrade, was stuck 2 min with this stupid halt with no information, and then, complete the upgrade ... after that, quagga was simply broken .. dynamic library has been upgraded .. and because Quagga is out of the official repository, it was logically the next to be broken ... so I just manually re-install it ..
It's ok for me now, all is working fine
See you and thanks for these information
EDIT : "Frankly, Arch isn't out to win some imaginary race. If we lose users like you because they're "bored" or whatever, then I'd say Arch actually wins.".
So for you, it's : why do it simple when you can make it complicated
That's it : Wonderful ...
There are developers like you, but you should not forget administrators, which are people who simply try to use your work. No administrators/users and developers will be alone ...
Last edited by loopx (2011-11-13 21:06:37)
Offline
You are really not serious.
So for you, it's : why do it simple when you can make it complicated
You have a funny definition of "simple". I can think of a lot of situations where this will flat out break a given setup. There is no "simple" when it comes to dealing with pre-existing files except for letting the user make the decision. Tools such as pacmatic exist for people such as yourself who are too busy to keep up with the news (~4 posts a month), but who have the time to bitch and moan about a file conflict on a package upgrade. In the time you've spent here, you could have looked at the existing /etc/profile.d/locale.sh, looked at the same file in the downloaded package, and made an intelligent, educated, decision about what to do.
There are developers like you, but you should not forget administrators, which are people who simply try to use your work. No administrators/users and developers will be alone ...
I'm a sysadmin during the day and maintain both Ubuntu and RHEL servers. pacman's behavior is very much similar to how RPM handles file conflicts with orphaned files. I have zero appreciation for the convoluted mess that is dpkg. Being that I volunteer time to hack on pacman during the evenings/weekends, I'd say that I haven't forgotten anything.
Offline
RPM and yum from RH move files out (what should do the initscripts package ...), keep configurations and don't stupidly ask what to do.
The file in conflict (/etc/profile.d/locale.sh) was containing only that :
export LANG=en_US.UTF-8
Should I care about this ? I don't think so since I never edited that file...
Now, this file is bigger :
if [ -s /etc/rc.conf ]; then
LANG=$(. /etc/rc.conf 2> /dev/null ; echo "${LOCALE:=en_US.UTF-8}")
fi
if [ -s /etc/locale.conf ]; then
. /etc/locale.conf
fi
export LANG LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE
export LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS
export LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION
... and you are telling me I should take care about that, I must know all about them ? About any shell script which are used to start services or set some vars of the system ? I tell you that this is stupid and can be skipped or simply inform the user doing the upgrade : this is an improvement for the default packet manager : pacman.
As "sysadmin", we should take care of configuration, but we don't have to take care of init-scripts which can/will evolve at any time.
If this is not a bug but a feature, that's a feature which waits for a user action to force it to manually update the new file ... new file you will update after a while (after upgrade complete and reboot done) and thus, what's the difference between that and an auto "mv X Y" + info ????? That's why this is stupid and will require many many stupid thread like this to change the current situation.
(your cat is really ugly)
EDIT: "In the time you've spent here, you could have looked at the existing /etc/profile.d/locale.sh, looked at the same file in the downloaded package, and made an intelligent, educated, decision about what to do."
And how can I see the newer file when pacman simply stop and cry for an error ? And how can I compare files if pacman don't trigger a "diff" between files ???
Last edited by loopx (2011-11-13 23:05:37)
Offline
May I suggest known work-arounds such as "# pacman -S filesystem --force; rm /etc/profile.d/locale.sh; pacman -Syu" are added to the Beginner Installation Guide -- until these "news" issues are fixed?
EDIT: Notes posted elsewhere.
Last edited by jesuschrist (2012-04-16 12:45:11)
Offline
Can we get new install disk images that do not have this issue? It is very annoying.
Offline
Can we get new install disk images that do not have this issue? It is very annoying.
Use the netinstall, should not have this problem.
Offline