Re: using perl in preinst script
On Fri, 31 Dec 2010, Carsten Hey wrote: * Philipp Kern [2010-12-29 05:38 +]: On 2010-12-28, Carsten Hey cars...@debian.org wrote: ... One reason for this is that dpkg's perl scripts were rewritten in C. I know you phrased it differently but wasn't the motivation for this rewrite to be more robust in the base system on upgrades? I.e. do not rely on Perl and thus avoid adding more contraints on how the base upgrade must be performed to keep dpkg working properly. I don't know what the main motivation was, although making upgrades more robust seems to be a possible and a good one. http://wiki.debian.org/Teams/Dpkg/RoadMap says: | Make dpkg.deb contain only sh and C programs (to help embedded | distros, to make it possible to remove perl-base from essential) Both points were important for me. I have dealt with the RC bug related to perl scripts failing in various preinst during an upgrade of perl-base/liblocale-gettext-perl and it was really annoying (i.e. we only had crude work-around and no proper solution). And I also maintain customer specific embedded systems where I am using udpkg to have some basic packaging system, I was avoiding dpkg due to the perl dependency. Dropping perl-base from essential on Debian proper is not a goal, but making it barely possible for some embedded derivatives is certainly interesting for us. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101231081950.gd3...@rivendell.home.ouaza.com
Re: using perl in preinst script
On 2010-12-30, Peter Samuelson pe...@p12n.org wrote: On 2010-12-28, Carsten Hey cars...@debian.org wrote: system. The remaining perl library packages could be removed after installing debconf-english. [Philipp Kern] You don't care about non-native speakers? SCNR. That's not how I read it at all. I think he's just saying, debconf-i18n requires perl, but that in itself is not a barrier to removing perl-base from Essential, because debconf-english (its alternative) does not need it. Obviously the discussion of what belongs in the Essential set is not at all the same thing as the discussion of what packages debootstrap should install by default (a base system). I know. It was ironic, thus the Sorry, could not resist.. I recently listened to a talk where there was a complaint about gdm running a full Gnome session and why the heck this was necessary. It was countered with so you don't care about disabled people!? argument because you want screenreader and input method infrastructure available. But that's way off-topic. ;) Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnihop2a.afk.tr...@kelgar.0x539.de
Re: using perl in preinst script
* Philipp Kern [2010-12-29 05:38 +]: On 2010-12-28, Carsten Hey cars...@debian.org wrote: ... One reason for this is that dpkg's perl scripts were rewritten in C. I know you phrased it differently but wasn't the motivation for this rewrite to be more robust in the base system on upgrades? I.e. do not rely on Perl and thus avoid adding more contraints on how the base upgrade must be performed to keep dpkg working properly. I don't know what the main motivation was, although making upgrades more robust seems to be a possible and a good one. http://wiki.debian.org/Teams/Dpkg/RoadMap says: | Make dpkg.deb contain only sh and C programs (to help embedded | distros, to make it possible to remove perl-base from essential) Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101231005641.ga6...@furrball.stateful.de
Re: using perl in preinst script
On Tue, 28 Dec 2010 15:07:56 -0800 Russ Allbery r...@debian.org wrote: Carsten Hey cars...@debian.org writes: We are not that far away from being able to implement this plan. The principle reason to consider not having perl / perl-base installed as part of a minimal base system (note that I don't claim that this involves using what Debian deems Essential) is to achieve a flavour of Debian with installation sizes below 64Mb, preferably closer to 32Mb. Therefore, Emdebian did a lot of work in this area for Lenny and finally got a version out which we called Emdebian Crush. It was so much work that there will be no subsequent version until at least after Wheezy. It's not just the cross-building issues (which are significant and which are waiting for Multiarch), it's not just the avoidance of perl in the final system (which is - or was with Lenny - also non-trivial), it is the rest of the system. 0: Custom installation methods are needed, which make testing harder 1: Other packages have to be rebuilt with different configuration options to drop long dependency chains like ldap, again complicating debugging / testing. 2: coreutils is another favourite for replacement and even a maximally reconfigured busybox cannot do the full job - dozens of maintainer scripts and other utilities rely on options for common commands which just aren't supported by busybox. (Not counting the problems that the Debian d-i team prefer to use a version of busybox which is old compared to busybox upstream stable.) 3: As Russ points out, working out the actual dependencies of the revised packages is just hard. There are other distributions out there which can handle these problems using the upstream sources but what makes Debian appealing are the maintainer scripts, the coordination, the way things fit together and these benefits are easily lost when making fundamental changes like those needed for Emdebian Crush or a similar sized installation. Even doing all that and getting down to under 64Mb, the number of machines which need such a constraint is getting small - most of the ones that people think of actually have constraints closer to 16Mb or less. At that point, you have to look at uClibc, busybox, customised kernel, a shell, a bit of networking and, umm, that's about it. That isn't Debian any more. It's a truly vast amount of work and what we'd get isn't really what these devices actually need. I've been working around these problems for years now, it just isn't achievable without an insane amount of resources and Debian/Emdebian doesn't have even a fraction of what would be required. Pushing this further is, IMNSHO, a sad case of NotInventedHere syndrome. Just because Debian doesn't have a way of doing this does not mean we need to invent a way of doing it when others have already solved the problems in ways which aren't compatible with how Debian needs to operate. If you want Debian/Emdebian on your system, be prepared to use a modern amount of SSD storage (= 128Mb) and get something you actually recognise as Debian. It'll make development easier because the debugger can work on the same symbols as on your main desktop workstation. After debootstraping the minbase variant of sid, installing file-rc and removing insserv, there is not much perl left in the newly created system. The remaining perl library packages could be removed after installing debconf-english. Far better to use Emdebian Grip which removes stuff from the existing packages without changing compatibility or functionality. It won't make the installation size minimally small but it'll still be 40% of the size of the equivalent Debian installation. Small enough for most cases. http://www.emdebian.org/grip/ Removing Perl requirements from the base system is not the hard part of removing something from essential. It's not the only hard part of making a minimal system either. The work required to fix package dependencies for the removal of perl-base from the essential set is extensive enough, not to mention unlikely (at least IMO) to be something that enough Debian developers are willing to work on, that I don't think it's worth taking extra precautions just in the unlikely case that it would happen. Sadly that's all too true. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpfbS7ub6gRY.pgp Description: PGP signature
Re: using perl in preinst script
On 2010-12-28, Carsten Hey cars...@debian.org wrote: system. The remaining perl library packages could be removed after installing debconf-english. [Philipp Kern] You don't care about non-native speakers? SCNR. That's not how I read it at all. I think he's just saying, debconf-i18n requires perl, but that in itself is not a barrier to removing perl-base from Essential, because debconf-english (its alternative) does not need it. Obviously the discussion of what belongs in the Essential set is not at all the same thing as the discussion of what packages debootstrap should install by default (a base system). That said, of course there are valid reasons not to even consider removing perl-base from Essential. Others have covered that ground already. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230013308.gf13...@p12n.org
Re: using perl in preinst script
* Russ Allbery [2010-12-27 08:49 -0800]: Luk Claes l...@debian.org writes: I thought there were some plans to try to get rid of perl-base being essential, in that case only shell (or C?) is a real alternative. We are not that far away from being able to implement this plan. One reason for this is that dpkg's perl scripts were rewritten in C. After debootstraping the minbase variant of sid, installing file-rc and removing insserv, there is not much perl left in the newly created system. The remaining perl library packages could be removed after installing debconf-english. Remaining perl scripts are: * chkdupexe from util-linux: This is short and could easily be replaced by something written in C. Alternatively, the following untested snippet could be prepended to chkdupexe: #!/bin/sh [ -x /usr/bin/perl ] exec perl -x -- $0 $@ echo 2 Please install the package perl-base. exit 1 * debconf: cdebconf exists and there is bug #328498 about switching to cdebconf as default, blocked by four other bugs. * pam_getenv and pam-auth-update from libpam-runtime: pam_getenv is 76 lines of code. pam-auth-update is 490 lines of code and has been added after Lenny has been released. Additionally, the preinst and postrm scripts of linux-image-* are written in perl and kernel-package generates packages with perl maintainer scripts. Using debhelper to add the dependencies on perl-base for packages that need them could reduce the required effort. Doing this early would ease ensuring sane upgrade paths. I cannot imagine this ever happening at a practical level. Not if people continue to add new perl scripts to essential and to write new preinst scripts in perl. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101228224818.ga23...@furrball.stateful.de
Re: using perl in preinst script
Carsten Hey cars...@debian.org writes: We are not that far away from being able to implement this plan. One reason for this is that dpkg's perl scripts were rewritten in C. After debootstraping the minbase variant of sid, installing file-rc and removing insserv, there is not much perl left in the newly created system. The remaining perl library packages could be removed after installing debconf-english. Removing Perl requirements from the base system is not the hard part of removing something from essential. The work required to fix package dependencies for the removal of perl-base from the essential set is extensive enough, not to mention unlikely (at least IMO) to be something that enough Debian developers are willing to work on, that I don't think it's worth taking extra precautions just in the unlikely case that it would happen. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkrph4xf@windlord.stanford.edu
Re: using perl in preinst script
On Tue, Dec 28, 2010 at 11:48:18PM +0100, Carsten Hey wrote: * pam_getenv and pam-auth-update from libpam-runtime: pam_getenv is 76 lines of code. pam-auth-update is 490 lines of code and has been added after Lenny has been released. And the lack of pam-auth-update has been a glaring gap in Debian functionality for the better part of a decade before that. I'm not dropping pam-auth-update from the package, and I'm not rewriting it in C or in shell because I don't believe either would make for a suitably maintainable implementation. I took great care to implement pam-auth-update using only the Essential functionality guaranteed to be available, which in some cases meant avoiding perl modules that would have made for cleaner code. If Debian were to drop perl-base from Essential, then I might as well rewrite pam-auth-update in python. perl-base's Essential status was the *only* reason for implementing this in perl to begin with. I cannot imagine this ever happening at a practical level. Not if people continue to add new perl scripts to essential and to write new preinst scripts in perl. Which there is zero reason for anyone to go out of their way to avoid doing. I don't see any way that it would benefit Debian to drop perl from the base system and limit ourselves to C, C++, and shell as implementation languages. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: using perl in preinst script
* Steve Langasek [2010-12-28 15:46 -0800]: On Tue, Dec 28, 2010 at 11:48:18PM +0100, Carsten Hey wrote: * pam_getenv and pam-auth-update from libpam-runtime: pam_getenv is 76 lines of code. pam-auth-update is 490 lines of code and has been added after Lenny has been released. And the lack of pam-auth-update has been a glaring gap in Debian functionality for the better part of a decade before that. I'm not dropping pam-auth-update from the package, and I'm not rewriting it in C or in shell ... I neither suggested dropping it nor that you should rewrite it and did not question that it is useful. If existing perl scripts would be rewritten, this would be something to be done by people wanting to make perl non-essential in agreement with the according maintainers. Also I did not say that perl-base should be made non-essential, I did list what is missing from being able to do so. I cannot imagine this ever happening at a practical level. Not if people continue to add new perl scripts to essential and to write new preinst scripts in perl. Which there is zero reason for anyone to go out of their way to avoid doing. One reason would be to avoid a possible later rewrite (in python and done by you in your case) if it would be decided that perl-base should be made non-essential in future. This was not meant as attack or to let libpam-runtime appear as bad example (which it is not), I wanted to point that if there are plans to make perl-base non-essential, then we should all avoid doing things that would make fulfilling this plan more difficult and if there is no such plan, than there is no point in avoiding writing preinst or postrm scripts in perl or avoiding to use perl in essential packages. Due to the missing consensus there is currently no right or wrong and the most sane thing is to assume that everything stays as it is now. This missing consensus leads to more workload, either for people avoiding perl in maintainer scripts and essential packages because they wrongly assume that perl-base might become non-essential, or because of writing perl scripts that are going to be replaced by implementations in other languages. I don't see any way that it would benefit Debian to drop perl from the base system and limit ourselves to C, C++, and shell as implementation languages. There are advantages of having a small minimal Debian installation (i.e., essential + apt), but there are more worthwhile things to do than removing a language from essential to save 4 MB. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101229015255.gb31...@furrball.stateful.de
Re: using perl in preinst script
On 2010-12-28, Carsten Hey cars...@debian.org wrote: * Russ Allbery [2010-12-27 08:49 -0800]: Luk Claes l...@debian.org writes: I thought there were some plans to try to get rid of perl-base being essential, in that case only shell (or C?) is a real alternative. We are not that far away from being able to implement this plan. One reason for this is that dpkg's perl scripts were rewritten in C. I know you phrased it differently but wasn't the motivation for this rewrite to be more robust in the base system on upgrades? I.e. do not rely on Perl and thus avoid adding more contraints on how the base upgrade must be performed to keep dpkg working properly. After debootstraping the minbase variant of sid, installing file-rc and removing insserv, there is not much perl left in the newly created system. The remaining perl library packages could be removed after installing debconf-english. You don't care about non-native speakers? SCNR. The cdebconf bugs look like there's still a bit of development to do. But maybe there's a slight chance it could be ready for wheezy, at least as an alternative. (But then there's also a slight chance that it could still contain Perl scripts.) Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnihlibe.9bj.tr...@kelgar.0x539.de
Re: using perl in preinst script
On Mon, 27 Dec 2010 16:53:11 +0530 Rahul Amaram amaramra...@users.sourceforge.net wrote: As the upgrade code has to parse .plist files, writing shell script would be a very difficult task. So I would like to know what are my other options? Could I write it in perl? $ file /var/lib/dpkg/info/*.preinst|grep -v shell script text Yes preinst scripts can be in perl - the other alternative is a compiled executable but that is only really an option if the package itself is already Arch:any. So, your packge is left with perl if shell isn't practical. I don't know the package but sometimes it is only necessary to identify that the upgrade needs to be run in the preinst and then actually handle the workload in the postinst (when you could use python), maybe via a dpkg trigger. What portion of the *results* of the parsing is actually required for the configuration of calendarserver itself? It is worth investigating whether a preinst is actually required or whether the work can be postponed. Also is there any estimate date on the release of squeeze? When the RC bugs are fixed. It seems unlikely that this particular package would affect the release as the new version won't migrate into testing now anyway - the broken preinst / Pre-Depends-not-discussed-previously-on-devel issue only exists in unstable and that can be fixed without affecting the release of Squeeze. (It does need to be fixed though.) -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpNhbCWqbQpm.pgp Description: PGP signature
Re: using perl in preinst script
]] Rahul Amaram | I am the maintainer for calendarserver. I have a query reg. preinst | script. I need to perform some action during preinst before the upgrade of | calendarserver happens from 1.x to 2.x. For this, I wrote the necessary | code in python in preinst script. But this was rejected into being accepted | into squeeze as writing python code or calling the python interpreter in | preinst is not permitted. As long as you have the necessary Pre-Depends, that should be fine, I'd imagine. (You have to discuss adding the pre-depends on debian-devel, but as long as you have a good reason to, I don't see a problem with that.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vzbbe6q@qurzaw.varnish-software.com
Re: using perl in preinst script
On Mon, Dec 27, 2010 at 04:53:11PM +0530, Rahul Amaram wrote: Hi, I am the maintainer for calendarserver. I have a query reg. preinst script. I need to perform some action during preinst before the upgrade of calendarserver happens from 1.x to 2.x. For this, I wrote the necessary code in python in preinst script. But this was rejected into being accepted into squeeze as writing python code or calling the python interpreter in preinst is not permitted. Yeah, you can count on dependencies being installed in postinst but not preinst (nor postrm purge). One solution would be to move your script to postinst if that's possible. Another would be to add a Pre-Dependency, although they are frowned upon unless there's no better way. If your script is relatively simple, I'd go with perl as you said. As the upgrade code has to parse .plist files, writing shell script would be a very difficult task. So I would like to know what are my other options? Could I write it in perl? Sure, as long as you don't use any modules not present in perl-base. cheers. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101227120218.ga20...@angband.pl
Re: using perl in preinst script
On Mon, 27 Dec 2010 13:19:57 +0100 Tollef Fog Heen tfh...@err.no wrote: ]] Rahul Amaram | I am the maintainer for calendarserver. I have a query reg. preinst | script. I need to perform some action during preinst before the | upgrade of calendarserver happens from 1.x to 2.x. For this, I | wrote the necessary code in python in preinst script. But this was | rejected into being accepted into squeeze as writing python code or | calling the python interpreter in preinst is not permitted. As long as you have the necessary Pre-Depends, that should be fine, I'd imagine. (You have to discuss adding the pre-depends on debian-devel, but as long as you have a good reason to, I don't see a problem with that.) See #608099 for rejection of the python preinst - as python is not essential, a Pre-Depends on python isn't workable. Good reason or no, there is a problem with a python preinst. Perl is a suitable alternative. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpig07FLbeYj.pgp Description: PGP signature
Re: using perl in preinst script
Hi, Thanks a lot for the prompt responses. I am a new maintainer (sponsored) and so not aware of some issues. I really appreciate all the help given in the list. Continuing with my previous mail, this is what the preinst script does: - Read the current caldavd.plist configuration file if it exists - If NSS directory service is configured in caldavd.plist, perform some action on caldavd data directories for those NSS users and groups And this has to be done before the upgraded calendarserver runs for the first time. Hence running it in postinst is not an option. As I can see, my only option seems to be using perl-base. But that still leaves me with a difficulty because to use the Plist parser module I will have to include many other modules. Not sure how to handle this. This is something I'll have to figure out. Anyway, keeping that apart, is there any chance that the upgraded calendarserver could be pushed into squeeze if I make those changes now? The reason being I am extremely occupied with other tasks and if this package cannot be pushed into squeeze I'd rather work on it after a while. Thanks, Rahul. On Mon, 27 Dec 2010 12:45:26 +, Neil Williams codeh...@debian.org wrote: On Mon, 27 Dec 2010 13:19:57 +0100 Tollef Fog Heen tfh...@err.no wrote: ]] Rahul Amaram | I am the maintainer for calendarserver. I have a query reg. preinst | script. I need to perform some action during preinst before the | upgrade of calendarserver happens from 1.x to 2.x. For this, I | wrote the necessary code in python in preinst script. But this was | rejected into being accepted into squeeze as writing python code or | calling the python interpreter in preinst is not permitted. As long as you have the necessary Pre-Depends, that should be fine, I'd imagine. (You have to discuss adding the pre-depends on debian-devel, but as long as you have a good reason to, I don't see a problem with that.) See #608099 for rejection of the python preinst - as python is not essential, a Pre-Depends on python isn't workable. Good reason or no, there is a problem with a python preinst. Perl is a suitable alternative. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8449e9fb844716f6cbbdd39b27f57...@localhost
Re: using perl in preinst script
On Mon, 27 Dec 2010 18:27:10 +0530 Rahul Amaram amaramra...@users.sourceforge.net wrote: - Read the current caldavd.plist configuration file if it exists - If NSS directory service is configured in caldavd.plist, ... then stop processing in the preinst at this point and set the config to not use NSS until configured. perform some action on caldavd data directories for those NSS users and groups ... so do this in postinst then restart with the updated config. And this has to be done before the upgraded calendarserver runs for the first time. Stop the server in the preinst (if not already stopped in the prerm of the old version) and don't start it until the postinst has finished doing the changes. Don't expect the server to be running between running the preinst and the postinst. Servers should be stopped before unpacking and restarted afterwards, in the postinst and after any config changes have been implemented. Hence running it in postinst is not an option. Actually, it probably is the only option. If necessary, consider changing the server so that it can run without needing this change. More commonly, ensure it is stopped in preinst and not started until after the postinst has finished. Anyway, keeping that apart, is there any chance that the upgraded calendarserver could be pushed into squeeze if I make those changes now? No. Squeeze is already in deep freeze. Only RC bug fixes are going to be accepted. It is too late to get non-RC bug fixes into Squeeze and the version in testing is not RC buggy (the version in unstable is potentially RC buggy). You'll just have to fix it in unstable and backport later. The reason being I am extremely occupied with other tasks It's too late - Debian releases take long enough as it is without waiting for everyone to have free time for their pet fixes to get in. and if this package cannot be pushed into squeeze I'd rather work on it after a while. You'll need to work on the package in unstable sooner rather than later. The version is unstable is buggy. Sooner or later you'll end up with a bug report that the preinst failed because python is not guaranteed to be configured when the preinst starts and that bug report would probably be RC. If you can't work on that now, pull the python preinst change out of the version in unstable and leave NSS configuration to the admin. Put something into README.Debian or News. Whatever you decide, the version in unstable does need to be fixed. You cannot expect a python preinst to actually work. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpX8NH7udDi9.pgp Description: PGP signature
Re: using perl in preinst script
On 12/27/2010 01:45 PM, Neil Williams wrote: On Mon, 27 Dec 2010 13:19:57 +0100 Tollef Fog Heen tfh...@err.no wrote: ]] Rahul Amaram | I am the maintainer for calendarserver. I have a query reg. preinst | script. I need to perform some action during preinst before the | upgrade of calendarserver happens from 1.x to 2.x. For this, I | wrote the necessary code in python in preinst script. But this was | rejected into being accepted into squeeze as writing python code or | calling the python interpreter in preinst is not permitted. As long as you have the necessary Pre-Depends, that should be fine, I'd imagine. (You have to discuss adding the pre-depends on debian-devel, but as long as you have a good reason to, I don't see a problem with that.) See #608099 for rejection of the python preinst - as python is not essential, a Pre-Depends on python isn't workable. Good reason or no, there is a problem with a python preinst. Perl is a suitable alternative. I thought there were some plans to try to get rid of perl-base being essential, in that case only shell (or C?) is a real alternative. Though in most cases including this one there is no real need to have the service running during the upgrade and you can easily do python or perl in the postinst. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d18a65c.5040...@debian.org
Re: using perl in preinst script
Hi Neil, Thanks for the response. I didn't intend to work on this update as per my leisure. I greatly admire the Debian release team for the effort they put in, in trying to make Debian a great experience to the end users. As I've already told you, I am new and therefore didn't know of the deep-freeze of Squeeze. Or else I would have definitely worked on it earlier itself. Anyway, coming back to the solution. This is what I plan to do. Kindly provide any necessary feedback. 1. Stop the server in preinst and if necessary copy the current configuration file to a temporary location. 2. In postinst, write python code to check if NSS directory service is being used (by parsing the configuration file) and if so take the appropriate action. Once this is done, delete the temporary copy of configuration file. Also I believe for this, python needn't be added to Pre-Depends but only to Depends. Pushing this script would make upgrade of calendarserver data directories seamless to end users who use NSS directory backend. This is the reason why I am so keen on pushing in this change so that the upgrade will cause the least inconvenience to end users. If the above solution is acceptable, then I will work on it right away. If not, then I'll consider removing python from the preinst script altogether as rewriting it in perl/shell is a really huge task for me. Cheers, Rahul. On Monday 27 December 2010 07:12 PM, Neil Williams wrote: On Mon, 27 Dec 2010 18:27:10 +0530 Rahul Amaramamaramra...@users.sourceforge.net wrote: - Read the current caldavd.plist configuration file if it exists - If NSS directory service is configured in caldavd.plist, ... then stop processing in the preinst at this point and set the config to not use NSS until configured. perform some action on caldavd data directories for those NSS users and groups ... so do this in postinst then restart with the updated config. And this has to be done before the upgraded calendarserver runs for the first time. Stop the server in the preinst (if not already stopped in the prerm of the old version) and don't start it until the postinst has finished doing the changes. Don't expect the server to be running between running the preinst and the postinst. Servers should be stopped before unpacking and restarted afterwards, in the postinst and after any config changes have been implemented. Hence running it in postinst is not an option. Actually, it probably is the only option. If necessary, consider changing the server so that it can run without needing this change. More commonly, ensure it is stopped in preinst and not started until after the postinst has finished. Anyway, keeping that apart, is there any chance that the upgraded calendarserver could be pushed into squeeze if I make those changes now? No. Squeeze is already in deep freeze. Only RC bug fixes are going to be accepted. It is too late to get non-RC bug fixes into Squeeze and the version in testing is not RC buggy (the version in unstable is potentially RC buggy). You'll just have to fix it in unstable and backport later. The reason being I am extremely occupied with other tasks It's too late - Debian releases take long enough as it is without waiting for everyone to have free time for their pet fixes to get in. and if this package cannot be pushed into squeeze I'd rather work on it after a while. You'll need to work on the package in unstable sooner rather than later. The version is unstable is buggy. Sooner or later you'll end up with a bug report that the preinst failed because python is not guaranteed to be configured when the preinst starts and that bug report would probably be RC. If you can't work on that now, pull the python preinst change out of the version in unstable and leave NSS configuration to the admin. Put something into README.Debian or News. Whatever you decide, the version in unstable does need to be fixed. You cannot expect a python preinst to actually work. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d18bfa0.2040...@users.sourceforge.net
Re: using perl in preinst script
On 2010-12-27, Rahul Amaram amaramra...@users.sourceforge.net wrote: Thanks for the response. I didn't intend to work on this update as per my leisure. I greatly admire the Debian release team for the effort they put in, in trying to make Debian a great experience to the end users. As I've already told you, I am new and therefore didn't know of the deep-freeze of Squeeze. Or else I would have definitely worked on it earlier itself. I'd advise you to read the mailing list debian-devel-announce, which is mandatory to read for all Debian Developers and should thus also be read by contributors. That's also the place where such status changes /:x updates are published. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnihhge8.65i.tr...@kelgar.0x539.de
Re: using perl in preinst script
On Tue, Dec 28, 2010 at 00:32, Rahul Amaram amaramra...@users.sourceforge.net wrote: Hi Neil, Thanks for the response. I didn't intend to work on this update as per my leisure. I greatly admire the Debian release team for the effort they put in, in trying to make Debian a great experience to the end users. As I've already told you, I am new and therefore didn't know of the deep-freeze of Squeeze. Or else I would have definitely worked on it earlier itself. Anyway, coming back to the solution. This is what I plan to do. Kindly provide any necessary feedback. 1. Stop the server in preinst and if necessary copy the current configuration file to a temporary location. 2. In postinst, write python code to check if NSS directory service is being used (by parsing the configuration file) and if so take the appropriate action. Once this is done, delete the temporary copy of configuration file. Also I believe for this, python needn't be added to Pre-Depends but only to Depends. I still think adding python to Depends only because a maintainer script needs it is costing too much, if the application itself doesn't need python at all. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinvco8vf+ns3k1+6kbxgz2corze9arx4_ojc...@mail.gmail.com
Re: using perl in preinst script
Luk Claes l...@debian.org writes: I thought there were some plans to try to get rid of perl-base being essential, in that case only shell (or C?) is a real alternative. I cannot imagine this ever happening at a practical level. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739pj2mar@windlord.stanford.edu
Re: using perl in preinst script
Thanks Philips. I've subscribed to the debian-devel-announce list. Is it also necessary that I subscribe to debian-announce i.e. will posts to debian-announce be automatically marked to debian-devel-annouce? On Monday 27 December 2010 10:11 PM, Philipp Kern wrote: On 2010-12-27, Rahul Amaramamaramra...@users.sourceforge.net wrote: Thanks for the response. I didn't intend to work on this update as per my leisure. I greatly admire the Debian release team for the effort they put in, in trying to make Debian a great experience to the end users. As I've already told you, I am new and therefore didn't know of the deep-freeze of Squeeze. Or else I would have definitely worked on it earlier itself. I'd advise you to read the mailing list debian-devel-announce, which is mandatory to read for all Debian Developers and should thus also be read by contributors. That's also the place where such status changes /:x updates are published. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d18c94d.8090...@users.sourceforge.net
Re: using perl in preinst script
The package depends on python anyways. My only query is as I am using python in postinst script, is it sufficient to mention it as part of Depends or should it still be mentioned in Pre-Depends? Apart from that, as per the response given by Neil and also my sponsorer, I think the below logic should do fine for the upgrade script. Thanks, Rahul. On Monday 27 December 2010 10:16 PM, Aron Xu wrote: On Tue, Dec 28, 2010 at 00:32, Rahul Amaram amaramra...@users.sourceforge.net wrote: Hi Neil, Thanks for the response. I didn't intend to work on this update as per my leisure. I greatly admire the Debian release team for the effort they put in, in trying to make Debian a great experience to the end users. As I've already told you, I am new and therefore didn't know of the deep-freeze of Squeeze. Or else I would have definitely worked on it earlier itself. Anyway, coming back to the solution. This is what I plan to do. Kindly provide any necessary feedback. 1. Stop the server in preinst and if necessary copy the current configuration file to a temporary location. 2. In postinst, write python code to check if NSS directory service is being used (by parsing the configuration file) and if so take the appropriate action. Once this is done, delete the temporary copy of configuration file. Also I believe for this, python needn't be added to Pre-Depends but only to Depends. I still think adding python to Depends only because a maintainer script needs it is costing too much, if the application itself doesn't need python at all. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d18ca41.2010...@users.sourceforge.net
Re: using perl in preinst script
Rahul Amaram amaramra...@users.sourceforge.net writes: The package depends on python anyways. My only query is as I am using python in postinst script, is it sufficient to mention it as part of Depends or should it still be mentioned in Pre-Depends? Depends is sufficient for postinst configure in the absence of circular dependencies. Other postinst actions have different restrictions and expectations about what dependencies are satisfied. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lj3b15bs@windlord.stanford.edu
Re: using perl in preinst script
On 2010-12-27, Rahul Amaram amaramra...@users.sourceforge.net wrote: Thanks Philips. I've subscribed to the debian-devel-announce list. Is it also necessary that I subscribe to debian-announce i.e. will posts to debian-announce be automatically marked to debian-devel-annouce? No, debian-announce has press releases, which aren't as essential to the developers. But if you wonder about $release getting released, then you should subscribe to it, too. They aren't copied to d-d-a. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnihhnpp.6aq.tr...@kelgar.0x539.de
