On Tuesday 03 August 2010 06:52:45 J. W. Birdsong wrote:

Great point; but we could at least mention **Restart Dovecot with #/etc/rc.d/dovecot restart** (or some such msg) in the dovecot.install file. Because we know EVERYONE reads the pacman msg(s) after an install. Regardless I think that is the solution best hoped for. David perhaps a bug/feature request asking for same??

Why should a message be printed ? If you've installed dovecot, and you see a dovecot update, you should know you have to restart this service after the upgrade. -- Nicolas D (aka slubman) site : http://www.slubman.info/

On Tue, 03 Aug 2010 01:00:09 -0500 "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:

Well sometimes the stupid ones among us don't always catch that dovecot is being updated when it is one of 73+ updates that take place. But we 'do' always catch the failure to copy to sent -- later :p

Seriously, one KISS thing that really works for Arch is having the little 1-line notes that are printed during update like:

No useless "little 1-line notes" only ment for braindead users.. i only want to see what i need to see. Dieter

On Tuesday 03 Aug 2010 at 09:28 Magnus Therning wrote:

...

No useless "little 1-line notes" only ment for braindead users.. i only want to see what i need to see.

I doubt I'm as knowledgeable on Linux systems as you, so I'd rather like seeing a bit more messages than you need to see.

I have to admit that the recent dovecot update caught me out too for a few minutes, until I realised that I'd had no new email for an eerie amount of time. But I don't think it's quite as simple as "there shouldn't be messages like this" or that it's about "linux experience". In my experience, some packages are affected differently than others when they are upgraded while running. Here are three different examples in my anecdotal experience (details may be incorrect): - Dovecot: a running instance appears to totally break and need restarting. - KDE: session needs restarting to run the new desktop, but the old one will carry on running happily, possibly causing the occasional problem. Newly launched apps are the new version (can lead to further problems). - Firefox: everything seems fine to carry on fine. Restart the instance at your leisure. With a particular package, you've no idea which category this falls into. Sure, you could apply the safest approach of always restarting everything that's upgraded, but that's not always practical. IMO it would be nice to have short indicators when something is likely to severely break until restarted. I don't think that's overkill, it's just helpful. Cheers, Pete.

On 08/03/2010 04:14 AM, Peter Lewis wrote:

With a particular package, you've no idea which category this falls into. Sure, you could apply the safest approach of always restarting everything that's upgraded, but that's not always practical. IMO it would be nice to have short indicators when something is likely to severely break until restarted. I don't think that's overkill, it's just helpful.

Cheers,

Pete.

Dieter, I get what you are saying and I agree. I don't want to see a multitude of little 1-liners winking by every time I upgrade, but both Magnus and Pete have a point. The general body of Arch users probably need to see a bit more info than you do (no doubt I do), but Pete really puts in into context. For those apps where an upgrade is likely to render the app broken until a restart, then I think that a one-liner is called for to help all of us that aren't full time devs know what packages *must* be restarted after update so that critical apps don't remain broken until something has risen to the level of a problem. I look at this discussion is just a good thought process at how Arch can be made more robust. Here setting the Arch standard for 1-liners and limiting them to what you need to see + 1-liners for apps that will be rendered inoperative as a result of an update just makes sense. I'm sure the list of apps that would need 1-liners from breakage after update are less than 10 so it wouldn't add much chatter at all to the upgrade messages. For things like MTA's, web-servers and the like adding them would just make Arch that much better. Maybe the Arch Santa will slip a few into his bag of presents this year. I've been good -- I promise :p -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

Hi, On Wednesday 04 Aug 2010 at 06:22 Andreas Radke wrote:

You seem to want to use a distribution made safe for less skilled users. Why do you keep wasting our time suggesting to make Arch something it's not meant to be???

I don't think that David necessarily does want this, and I hope no one will mind mind if I say that I don't think this is really a very helpful response. David has come to the list and asked a question, since pacman didn't behave the way he expected it to (albeit from experience from other distros) - which is valid. David's original question of "why didn't/shouldn't pacman restart dovecot" has been answered and I don't think that anyone thinks that paman should start doing things like that. I've learnt a reasonable amount about linux over the years, and a lot of it has been through asking (perhaps naive) questions on mailing lists. One thing I've learnt is that there's always someone who knows more than you and thinks your question is trivial, and there's always someone who barely understands what you're asking. It's not about overall world-of-warcraft-style linux skill points, it's just about where your knowledge is focused. For example, I just checked and I have 1394 packages installed on my laptop. I'll be damned if I can remember the eccentricities of all of them!

If Arch doesn't fit you needs you shouldn't use.

This is of course true, but in order to appreciate the beauty of a simple distro like Arch, one has to understand *why* Arch does things the way it does IMO. One way of doing this (of course in addition to reading the wiki etc) is to ask around. No one individual is obliged to answer.

If package updates and restarting a daemon is hard to handle for you should really think about this. You seem to hold the record in the last months for silly questions about updating and using our distribution.

Not helpful. See above. WARNING: Constructive part of the post!! :-)

If you think you need a list of packages to remember where you should interact, go on and create one your own.

Absolutely, why not? If someone really wants to implement this, why not have a flag set somewhere that tells pacman whether you want "package hints" or something turned on. Then let packages set a one line package hint. Not for everyone, but some people with poor memories (like me) might find it useful. Patches welcome? Cheers, Pete.

On Wed, Aug 4, 2010 at 04:07, Andreas Radke <a.radke@arcor.de> wrote:

Am Wed, 4 Aug 2010 09:22:41 +0100 schrieb Peter Lewis <pete@muddygoat.org>:

...

WARNING: Constructive part of the post!! :-)

...

If you think you need a list of packages to remember where you should interact, go on and create one your own.

Absolutely, why not? If someone really wants to implement this, why not have a flag set somewhere that tells pacman whether you want "package hints" or something turned on. Then let packages set a one line package hint. Not for everyone, but some people with poor memories (like me) might find it useful.

Patches welcome?

Cheers,

Pete.

Read again the Arch way: You make it what you want. We don't know if you install a pkg like dovecot to work on its documentation, to code stuff depending on its libs or headers or if you want to use it in its main direction as a daemon.

Why should we make Arch more and more complex just to satisfy a few of you with things that are almost self explaining???

If you run a daemon or application that gets upgraded it's first your fault you didn't stop it before and 2nd your task to decide after reading the Changelog/commit-list if you have to solve your mistake by restarting the stuff.

-Andy

One of the things I've learned with Arch is system administration. A talent I lost when I moved from DOS to Windows and one of the things I've learned to dislike about most of the major Linux distros. It's much easier to to the work when you do the install than when another persons version of how your box is set up breaks your box. As to making a list of things to do on upgrades, I made my own but It's only relevant to my machines and the software I have installed. Now I'm working on an install list and a package dependency list for all the software (started prior to the latest pacman release that grabs the deps for you when using makepkg). I have an extremely poor memory that's why I made my own lists. It's up to you the user to know how to maintain your own system. IMHO the Arch way is great. Now to step on some toes, both sides. Years ago I was pointed to esr's "How to ask questions the smart way". His philosophy is excellent and very relevant and provides many insights to developers. It took a long time for me to realize just how annoying someone can be. It also made me realize some of Gnome/Ubuntu's etc canned responses to filing bugs isn't a bad idea. If someone files a bug with little or incorrect information, they get a simple reply requesting the information they need. Not sure that would work on a mailing list, but it might be the way to go. It would let the user know they need to provide more info and possibly keep the agitated responses from developers down. I realize the developers are very busy and only work on Arch when they have time. They don't always have time to go through the twenty question routine of normal tech support and I appreciate that. I also appreciate the job their doing in making Arch the best Linux distro around. If someone were trolling, I can see an extremely tacky response. If someone just doesn't get it, I can see an extremely tacky response. I've seen some individuals like that on this mailing list. That makes it easier to understand tacky responses. The best response is the one you think about before firing away, no matter how agitated you are. I know that for a fact. After thirty years working in the oilfield service business, I given and received many quick agitated responses. A lot of them to the wrong people. Just my 2c worth. Myra -- Life's fun when your sick, psychotic, adhd challenged, and see the world in a different way.!

At Dienstag, 3. August 2010 08:00 David C. Rankin wrote:

Well sometimes the stupid ones among us don't always catch that

dovecot is

being updated when it is one of 73+ updates that take place. But we 'do' always catch the failure to copy to sent -- later :p

If the count of updates is your problem than this idea could be something for you: # cat /etc/cron.daily/pacman.updates #!/bin/sh { /usr/bin/pacman -Sy echo /usr/bin/pacman -Sup } | /usr/bin/mail -s "$(hostname -s): Arch Updates" YourUser No question, this is more simple than perfect. -) See you, Attila

On 08/02/2010 11:39 PM, Tavian Barnes wrote:

Because of KISS? Pacman is a package manager, not a system administration tool.

Imagine the story with a different daemon: SSH. You ssh into your box, su, and pacman -Syu. Halfway through the upgrade, openssh gets updated, which automatically restarts the server, which SIGHUPs pacman, which is left in an inconsistent state.

Thanks, That's all I needed to know. I'll keep a closer eye on the logs after update. My post wasn't to imply that pacman 'should' do it, it was just meant as a query of if it 'was' supposed to do it, it didn't :p I agree with the philosophy of having pacman NOT do it for any packages. There is brilliance in KISS. Once a few packages 'start' doing it, then there is a continual open question in users minds "Does package X have a post-install that does it -- or not?" -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

On 3 August 2010 03:04, Jan de Groot <jan@jgc.homeip.net> wrote:

On Mon, 2010-08-02 at 22:39 -0600, Tavian Barnes wrote:

...

Imagine the story with a different daemon: SSH.  You ssh into your box, su, and pacman -Syu.  Halfway through the upgrade, openssh gets updated, which automatically restarts the server, which SIGHUPs pacman, which is left in an inconsistent state.

OpenSSH is designed to keep its connection alive during restarts. You can even stop sshd without losing connection, as long as the rc.d script is not buggy (we had a buggy script that would kill all child processes too a while ago...)

Huh, I did not know that, cool. Still, the example works if you replace ssh with some hypothetical service that doesn't gracefully handle restarts. Or the worse case where the restart fails and you only notice 4 days later. -- Tavian Barnes

Am Tue, 03 Aug 2010 21:40:20 +0200 schrieb Attila <vodoo0904@sonnenkinder.org>:

Okay, i recognized that i wrote too much under this little thread so set it on read if this is too much for you.-)

...

I must admit, that I didn't read this completely. It's so simple and every Linux user should or must know this. If a daemon or any other software is updated it must be restarted either to use the new version or to get it working if the running version broken by the update. And the config files need to be checked and customized after every update. That's a common and necessary task of a Linux admin which doesn't need and in my opinion shouldn't be done by the package manager, because the package manager can't decide which config files I need or want to adjust and when I can and want to restart which daemon. Restarting daemons automatically by the package manager can break a lot and can do a lot more harm. And there are definitely no messages from the package manager needed. Just KISS and just a common and usual work of an admin. It just belongs to the basic knowledge. If a production server is updated then the users have to be informed before the update. Heiko

Am Tue, 3 Aug 2010 22:48:48 +0200 schrieb fons@kokkinizita.net:

Well, that depends. If a user is upgrading a package X explicitly then he/she is probably anticipating the consequences, and has prepared for them. If X is updated as a side effect that could be different, and a warning would be good thing.

Before the system is updated by `pacman -Syu` pacman shows you every package which will be updated and asks you if you really want to update. If someone is too lazy to read this list it's his own problem. And I doubt that someone who is too lazy to read pacman's package list will read the post install messages. Nevertheless such messages are not necessary because it's just basic knowledge and every Linux admin must know that daemons have to be restarted after updating. It's even better to stop the daemon before it's upgraded.

Again agreed. But some changes are quite invasive. Going from Xorg 1.7 to 1.8 without being prepared for it can hit you where it hurts. It happened to me just a few days ago (all is OK now).

I had no problem with the X upgrade. But I read the news on the homepage before I updated it. ;-) This explained everything I needed to know. Well, of course, every update can break something, but usually it's not a big issue. I'm using Linux since several years now, even if I'm still not omniscient, first SuSE, then Gentoo, now Arch Linux, and I never had any serious breakages. I even didn't made any backups of my old kernels before a kernel update. And I never had a problem with a kernel update. Well, I once had one serious issue but that was totally my fault, but I knew that this could happen before I did what I did. So not an issue at all. Heiko

Am Tue, 03 Aug 2010 21:59:10 +0100 schrieb Mario Figueiredo <marfig@gmail.com>:

An argument can be made that this approach makes a rolling release less attractive to users who have invested heavily in the supported repositories. I heard this much just recently from a former Arch user; The possibility of an an unpdate resulting in a post-update maintenance nightmare to get the machine up and running again can be a little scary.

I hadn't had any post-update maintenance nightmares yet. Well, not nightmares. I want to know what is done and what happens on my system. Otherwise I would recommend a different distro. But to be honest I had a lot more post-update nightmares with SuSE, because YaST has always overridden my configurations. This can't happen with Arch due to the .pacnew files. And I don't think `diff configfile configfile.pacnew` and an `/etc/rc.d/daemon restart` is such a nightmare. Arch is only scary if people don't want to learn Linux and read documentations. There are better distros for those people.

But I do agree with you. I just don't think that waving the KISS principle as a weapon achieves much. It's a tool. And it has its disadvantages. Users must be aware of them.

But with KISS you have the most control over your system. Well, there can be a few exceptions if they make sense. But this is not the case for daemon restarting.

If a user keeps the machine updated regularly and follows a tight upgrade schedule, they will have to deal with only minor incidents once and a while. And all easy to handle. Stop daemon, start daemon. On the other hand, if a user decides to update their machine once every two months, they must understand that it is not the rolling release system that is at fault. It's them for not understanding what's the point of a rolling release.

I totally agree. Heiko

Am Wed, 04 Aug 2010 07:14 +0200 schrieb Attila <vodoo0904@sonnenkinder.org>:

Only for the stats: In the case of updating packages Yast, and im suprised that you use this more than zypper, don't touch changed config files because opensuse, and every other rpm basesd distribution, do the same as archlinux with *.rpmsave and *.rpmnew files.

I'm not using openSUSE anymore. I used SuSE several years ago when there was only YaST and YaST2. So I don't know zypper. I admit that this comment was a little bit unfair on openSUSE. But I've written SuSE and it was my experience with it. ;-) Heiko

At Dienstag, 3. August 2010 22:35 Heiko Baums wrote:

That's a common and necessary task of a Linux admin which doesn't need and in my opinion shouldn't be done by the package manager, because the package manager can't decide which config files I need or want to adjust and when I can and want to restart which daemon. Restarting daemons automatically by the package manager can break a lot and can do a lot more harm.

Here i'm be with you but this problem with restarting daemons has more to do that we all enjoy this rolling releases under archlinux. In a case of a distribution which does this not you can do this without a problem in a lot of cases.

And there are definitely no messages from the package manager needed.

Before i saw this feature with the warning in zypper i would say here yes too but now i found this very useful because in the case of gui apps or the gui itself it is not even clear for me what for libs been used. I'm running opensuse on my laptop too and i'm often suprised after an update what for litte apps use what for libs. But no question, it would more say it is nice if it is there but not a thing what is absolutely necessary or that it is unacceptable that we users do this by ourselves. See you, Attila

At Samstag, 7. August 2010 01:26 Guus Snijders wrote:

Well, you certainly do have a point; finding out which apps are using the updated libraries etc would be nice.

Here is a example of the output and what it is behind: http://www.kriyayoga.com/love_blog/post.php/1207 How more i search in the web what is behind i found out that it seems that "zypper ps" run this only for the list of the updated packages and not for the whole system. This makes it very hard for myself to find out how i can get the same under archlinux.

After thinking about it for a moment, it seems one solution would be very simple. Just run "lsof | grep -i DEL".

It seems that you don't use KDE because i get a big list of '*kdelibs*' entries.-) One other human used this "lsof -n | grep -E 'RPMDELETE|;|path inode='" under opensuse before zypper get this feature. But RPMDELETE won't be there under archlinux.

I'm pretty sure that this could be much optimized, but i hope the idea is clear

If you find something for this this would be very, very nice.-) See you, Attila

At Samstag, 7. August 2010 23:07 Guus Snijders wrote:

In that case, try: lsof | grep " DEL "

Note the spaces before and after DEL. After checking it again, i noted that lsof uses caps for the type, so we can drop the -i from grep.

This idea is better and now i have to wait for an update which will use deleted files. Only for the stast it is not unusually that apps use deleted files: # lsof -n | grep ' DEL ' firefox 1832 arpad DEL REG 0,4 1998849 /SYSV00000000 kwin 3815 arpad DEL REG 0,4 0 /SYSV00000000 The way of an rpm based system with using RPMDELETE as the flag seems easier to find out such files. Is there a analog way possible for pacman? I never take a look after an update with pacman. See you, Attila

On Sat 07 Aug 2010 01:26 +0200, Guus Snijders wrote:

HTH, HAND

What?

On Sat, Aug 7, 2010 at 9:04 PM, Gary Wright <wriggary@gmail.com> wrote:

On Sat, Aug 7, 2010 at 3:31 PM, Loui Chang <louipc.ist@gmail.com> wrote:

...

On Sat 07 Aug 2010 01:26 +0200, Guus Snijders wrote:

...

HTH, HAND

What?

HTH[1] HAND[2]

[1] http://www.acronymfinder.com/HtH.html [2] http://www.acronymfinder.com/HAND.html

now we are just getting lazy