Re: [arch-general] Fix or not fix? install scriptlets with user handling.
On Samstag, 30. Mai 2009 15:37 Dan McGee wrote: > I think I can safely speak for most of the developers when I say Arch > will never get in the business of restarting daemons. Ever. If we do > it is a bug, because the implications of it are just too great. Think > about upgrading the httpd package on a relatively high-traffic site > (e.g. archlinux.org). Think we want the webserver to just restart > whenever it wants? Now do the same with xinetd, mysql, and you start > to see huge problems. I understand what you mean because i run a server at home and therefore i know about such possible problems. I'm only wondering that everybody think he is on the safe side that you don't restart it as a rule in every case. At example if the package is a daemon without any dependence to another one this is only defering a possible problem in the future to the next reboot, not more and for me not better. But i don't want to say that you have to change this because for a single daemon i would say that this is possible but for a combination of them as you said this is too much work for a problem who could (and should) be solved from the user. See you, Attila
Re: [arch-general] [arch-dev-public] .so bump - icu 4.2
Andreas Radke wrote: > I'm just loading new icu up to testing. This will requiere rebuilds > (from our packages webside): > > * brltty > * go-openoffice > * libflashsupport > * libwebkit > * openoffice-base > * openoffice-base-beta > * openoffice-base-devel > * tin > > > I'll do the rebuilds one by one. This will take some time especially > for the OOo packages... > > Please report if more packages will need a rebuild. > > -Andy > > Yes, [extra] is OK and this is from [community] dwdiff-1.5.2-1 libfbclient-2.1.2.18118-1 open-vm-tools-2009.04.23-5 openttd-0.7.0-1 parrot-1.0.0-3 sword-1.5.11-3 xiphos-3.0.1-2 yaz-3.0.45-1 -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Re: [arch-general] pidgin memory leak?
On Fri, May 29, 2009 at 9:22 PM, Jon Kristian Nilsen wrote: > Also try msn-pecan to see if maybe that one works better. > > -J WOW! msn-pecan is new to me. I'll give it a try. Thnx =] -- Malformed message exception
Re: [arch-general] http://bugs.archlinux.org/task/14873
On Sat, 2009-05-30 at 13:59 +0200, Damjan Georgievski wrote: > >> BTW, what is up with your emails coming in to the mailing list several > >> hours earlier than what you replied to. It is getting annoying... > > > > Don't know. The clock displayed in gnome is right to UTC and local. > > > > I may have started with my using evolution rather that thunderbird. > > I have used evolution to post all my emails for the month of June. > > You don't have your timezone set correctly, from your message: > > Received: from [192.168.1.50] by lapu-lapu.bildanet.com with esmtp (Exim 4.68) > (envelope-from ) id 1MACvt-0001zg-Rt > for arch-general@archlinux.org; Fri, 29 May 2009 21:00:21 -0400 > Date: Fri, 29 May 2009 21:00:20 + > > > You have the zone (i.e. UTC) while you need to have -0400 > probably (what timezone are you in?) > > so, you need to set your hardware clock to UTC if you use only Linux, > or to localtime if you dual-boot to Windows, and set rc.conf > accordingly. > I have set the time related things in /etc/rc.conf and installed and configured ntpd, so I should be good to go.
Re: [arch-general] Fix or not fix? install scriptlets with user handling.
Jan de Groot wrote: On Sat, 2009-05-30 at 08:37 -0500, Dan McGee wrote: I think I can safely speak for most of the developers when I say Arch will *never* get in the business of restarting daemons. Ever. If we do it is a bug, because the implications of it are just too great. Think about upgrading the httpd package on a relatively high-traffic site (e.g. archlinux.org). Think we want the webserver to just restart whenever it wants? Now do the same with xinetd, mysql, and you start to see huge problems. To process a kernel update, your system should be rebooted too. Should we do that from post_upgrade also? :P I agree with Dan here. I don't like packages restarting or stopping crap behind my back. Since we do not have configuration file merging integrated in pacman, I also see no way to do this in a good fashion. Let's say you upgrade apache 1.3 to 2.2, after which the configuration scheme has changed completely. Just stop the old apache, install apache 2.2, install a shitload of pacnew files, start apache and it fails and won't come up again until the administrator updates all configs. Compare this to the case where apache will keep running until the next run of logrotate where it will crash then. Or it could get even more confusing: http://www.ibiblio.org/harris/500milemail.html
Re: [arch-general] Fix or not fix? install scriptlets with user handling.
On Sat, 2009-05-30 at 08:37 -0500, Dan McGee wrote: > > I think I can safely speak for most of the developers when I say Arch > will *never* get in the business of restarting daemons. Ever. If we do > it is a bug, because the implications of it are just too great. Think > about upgrading the httpd package on a relatively high-traffic site > (e.g. archlinux.org). Think we want the webserver to just restart > whenever it wants? Now do the same with xinetd, mysql, and you start > to see huge problems. To process a kernel update, your system should be rebooted too. Should we do that from post_upgrade also? :P I agree with Dan here. I don't like packages restarting or stopping crap behind my back. Since we do not have configuration file merging integrated in pacman, I also see no way to do this in a good fashion. Let's say you upgrade apache 1.3 to 2.2, after which the configuration scheme has changed completely. Just stop the old apache, install apache 2.2, install a shitload of pacnew files, start apache and it fails and won't come up again until the administrator updates all configs. Compare this to the case where apache will keep running until the next run of logrotate where it will crash then. Another thing is upgrading in chroots. Last week I've been updating a debian etch chroot install to debian lenny. I had to edit the postrm and postinst files for postfix and snmpd, because they couldn't stop and start postfix and snmpd. Apt would not let me continue without fixing this first. I ended up with two chroots that didn't allow me to umount the bind-mounted /proc, /dev and such, with no way to find out which stupid daemon was still running inside the chroot.
Re: [arch-general] Fix or not fix? install scriptlets with user handling.
Dan McGee wrote: On Sat, May 30, 2009 at 6:54 AM, Daenyth Blank wrote: On Sat, May 30, 2009 at 05:28, ludovic coues wrote: Maybe that a PKGBUILD runned solution, could allow to set some pacman's config for this. Like a field " auto-restart_daemon = 1", wich you can set to 0, if you don't want. Same for adding user. If the field is to 1, pacman manage it by itself, if it's set to 0, pacman just print warning informing the user that he need to apply change to the daemon, i.e. restart it. -1. Pacman is a package manager, not a system administration tool. I think I can safely speak for most of the developers when I say Arch will *never* get in the business of restarting daemons. Ever. If we do it is a bug, because the implications of it are just too great. Think about upgrading the httpd package on a relatively high-traffic site (e.g. archlinux.org). Think we want the webserver to just restart whenever it wants? Now do the same with xinetd, mysql, and you start to see huge problems. BTW, this has been discussed in the bug track a couple of years ago: http://bugs.archlinux.org/task/9030 Allan
Re: [arch-general] Fix or not fix? install scriptlets with user handling.
On Sat, May 30, 2009 at 6:54 AM, Daenyth Blank wrote: > On Sat, May 30, 2009 at 05:28, ludovic coues wrote: >> Maybe that a PKGBUILD runned solution, could allow to set some >> pacman's config for this. >> Like a field " auto-restart_daemon = 1", wich you can set to 0, if you >> don't want. Same for adding user. >> >> If the field is to 1, pacman manage it by itself, if it's set to 0, >> pacman just print warning informing the user that he need to apply >> change to the daemon, i.e. restart it. >> > > -1. Pacman is a package manager, not a system administration tool. I think I can safely speak for most of the developers when I say Arch will *never* get in the business of restarting daemons. Ever. If we do it is a bug, because the implications of it are just too great. Think about upgrading the httpd package on a relatively high-traffic site (e.g. archlinux.org). Think we want the webserver to just restart whenever it wants? Now do the same with xinetd, mysql, and you start to see huge problems. -Dan
Re: [arch-general] http://bugs.archlinux.org/task/14873
>> BTW, what is up with your emails coming in to the mailing list several >> hours earlier than what you replied to. It is getting annoying... > > Don't know. The clock displayed in gnome is right to UTC and local. > > I may have started with my using evolution rather that thunderbird. > I have used evolution to post all my emails for the month of June. You don't have your timezone set correctly, from your message: Received: from [192.168.1.50] by lapu-lapu.bildanet.com with esmtp (Exim 4.68) (envelope-from ) id 1MACvt-0001zg-Rt for arch-general@archlinux.org; Fri, 29 May 2009 21:00:21 -0400 Date: Fri, 29 May 2009 21:00:20 + You have the zone (i.e. UTC) while you need to have -0400 probably (what timezone are you in?) so, you need to set your hardware clock to UTC if you use only Linux, or to localtime if you dual-boot to Windows, and set rc.conf accordingly. -- damjan
Re: [arch-general] Fix or not fix? install scriptlets with user handling.
On Sat, May 30, 2009 at 05:28, ludovic coues wrote: > Maybe that a PKGBUILD runned solution, could allow to set some > pacman's config for this. > Like a field " auto-restart_daemon = 1", wich you can set to 0, if you > don't want. Same for adding user. > > If the field is to 1, pacman manage it by itself, if it's set to 0, > pacman just print warning informing the user that he need to apply > change to the daemon, i.e. restart it. > -1. Pacman is a package manager, not a system administration tool.
Re: [arch-general] depends vs. makedepends
Magnus Therning wrote: Allan McRae wrote: Magnus Therning wrote: Allan McRae wrote: [..] As a general rule, you never should use $startdir in a PKGBUILD. Is that written down somewhere? It'd be nice to have a place to refer to when arguing some changes to PKGBUILDs. man PKGBUILD: startdir was most often used in combination with /src or /pkg postfixes, but use of the srcdir and pkgdir variables is preferred. The wording has been made even stronger about not using $startdir for the next pacman release. Ah, excellent, I wasn't aware of the existence of that man-page. Another thing that I've been wondering about is the relationship between 'depends' and 'makedepends'. The description in the man-page is fairly clear, but just to check I'm wondering if it's correct to say that 1. a dependency should _never_ be mentioned in both 'depends' and 'makedepends'? 2. the packages required to build a package is the union of 'depends' and 'makedepends'? Yes. They way I think about it is "depends" are needed to run a package and "makedepends" are extras needed to build the package. Allan
[arch-general] depends vs. makedepends (was: Re: http://bugs.archlinux.org/task/14873)
Allan McRae wrote: Magnus Therning wrote: Allan McRae wrote: [..] As a general rule, you never should use $startdir in a PKGBUILD. Is that written down somewhere? It'd be nice to have a place to refer to when arguing some changes to PKGBUILDs. man PKGBUILD: startdir was most often used in combination with /src or /pkg postfixes, but use of the srcdir and pkgdir variables is preferred. The wording has been made even stronger about not using $startdir for the next pacman release. Ah, excellent, I wasn't aware of the existence of that man-page. Another thing that I've been wondering about is the relationship between 'depends' and 'makedepends'. The description in the man-page is fairly clear, but just to check I'm wondering if it's correct to say that 1. a dependency should _never_ be mentioned in both 'depends' and 'makedepends'? 2. the packages required to build a package is the union of 'depends' and 'makedepends'? /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe signature.asc Description: OpenPGP digital signature
Re: [arch-general] http://bugs.archlinux.org/task/14873
Magnus Therning schrieb: Allan McRae wrote: [..] As a general rule, you never should use $startdir in a PKGBUILD. Is that written down somewhere? It'd be nice to have a place to refer to when arguing some changes to PKGBUILDs. /M You can regularly refer to the prototypes in /usr/share/pacman. Those have $srcdir and $pkgdir now (which are also necessary for the split package building in pacman 3.3). Other than that, I only noticed because the other devs started using them instead of $startdir. There is one reason to refer to $startdir, maybe we should think about that: The .install file is never included in source=(), but we sometimes sed stuff inside it, refering to $startdir. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Fix or not fix? install scriptlets with user handling.
> For me it's about 'expectations'. I expect a package manager to manage > packages > (unpack a new one over the old one in a sensible manner) and don't expect it > to > decide what's best for me in terms of what's running or not. I still find it > 100% better to *let me know* that config might have changed (pacman does > this > automatically) and that something might need to be done if, say, I run this > and > that daemon. Don't run it for me. And if you absolutely have to, *let me > know*. > > -- > Jan > Maybe that a PKGBUILD runned solution, could allow to set some pacman's config for this. Like a field " auto-restart_daemon = 1", wich you can set to 0, if you don't want. Same for adding user. If the field is to 1, pacman manage it by itself, if it's set to 0, pacman just print warning informing the user that he need to apply change to the daemon, i.e. restart it.
Re: [arch-general] http://bugs.archlinux.org/task/14873
Magnus Therning wrote: Allan McRae wrote: [..] As a general rule, you never should use $startdir in a PKGBUILD. Is that written down somewhere? It'd be nice to have a place to refer to when arguing some changes to PKGBUILDs. man PKGBUILD: startdir was most often used in combination with /src or /pkg postfixes, but use of the srcdir and pkgdir variables is preferred. The wording has been made even stronger about not using $startdir for the next pacman release. Allan
Re: [arch-general] http://bugs.archlinux.org/task/14873
Allan McRae wrote: [..] As a general rule, you never should use $startdir in a PKGBUILD. Is that written down somewhere? It'd be nice to have a place to refer to when arguing some changes to PKGBUILDs. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe signature.asc Description: OpenPGP digital signature
Re: [arch-general] Fix or not fix? install scriptlets with user handling.
Excerpts from Attila's message of Fr Mai 29 17:42:23 +0200 2009: > And still again i suggest to take a look at other distros where daemons get > restarted without a problem during a upgrade procedure. Sorry, but i find > this rule of "don't restart during the upgrade" a little bit academically.-) For me it's about 'expectations'. I expect a package manager to manage packages (unpack a new one over the old one in a sensible manner) and don't expect it to decide what's best for me in terms of what's running or not. I still find it 100% better to *let me know* that config might have changed (pacman does this automatically) and that something might need to be done if, say, I run this and that daemon. Don't run it for me. And if you absolutely have to, *let me know*. -- Jan
