Hi,
I am packaging gnumed-server. I have two issues which need to to corrected before I move it to bugzilla. You can find the spec file, the SRPM and the RPM here[1]
The issues are:
1) After installation, it creates the db gnumed_v2 and upgrade to gnumed_v14, one step at a time. This takes too long. Is there a way to create gnumed_v14 directly?
2) We need to figure a way to backup the databases and continue with bootstrapping quitely. Right now, it asks the user whether to continue or not.
3) Does this use any unpackaged library? If yes, it would be nice to know which
Helps are appreciated.
Thanks.
[1] http://susmit.fedorapeople.org/packaging/gnumed-server/
Am Donnerstag, 6. Januar 2011, 16:48:43 schrieb susmit shannigrahi:
Hi,
I am packaging gnumed-server. I have two issues which need to to corrected before I move it to bugzilla. You can find the spec file, the SRPM and the RPM here[1]
The issues are:
- After installation, it creates the db gnumed_v2 and upgrade to
gnumed_v14, one step at a time. This takes too long. Is there a way to create gnumed_v14 directly?
There is no way short of dumping a previously bootstraped database and restoring it.
But the packages does not need to do this. This only needs to be done a single time in the lifetime of an installation. It is not like to bootstrap every day. Trust me. We have some experience from users on Ubuntu. This is no problem at all.
- We need to figure a way to backup the databases and continue with
bootstrapping quitely. Right now, it asks the user whether to continue or not.
There is a switch to do that. Are you bootstraping as root ?
Anyways in each conf file there is a switch to make it silent. For the time being I would not worry about automatically bootstraping at all. Imagine a user has data and reinstalls. It will potentially overwrite it and the user will be unhappy :-)
- Does this use any unpackaged library? If yes, it would be nice to know
which
No black magic there.
I will have a look as soons as possible.
Sebastian
- After installation, it creates the db gnumed_v2 and upgrade to
gnumed_v14, one step at a time. This takes too long. Is there a way to create gnumed_v14 directly?
There is no way short of dumping a previously bootstraped database and restoring it.
But the packages does not need to do this. This only needs to be done a single time in the lifetime of an installation. It is not like to bootstrap every day. Trust me. We have some experience from users on Ubuntu. This is no problem at all.
Looks like we can not create/remove databases at all during the installation. That will be left for the user to do.
Anyways in each conf file there is a switch to make it silent. For the time being I would not worry about automatically bootstraping at all. Imagine a user has data and reinstalls. It will potentially overwrite it and the user will be unhappy :-)
If all bootstrapping does is to create databases and import data then we may need to think alternate method for it. Please refer to this: http://lists.fedoraproject.org/pipermail/devel/2011-January/147681.html
Thanks.
Am Sonntag, 9. Januar 2011, 19:54:04 schrieb susmit shannigrahi:
- After installation, it creates the db gnumed_v2 and upgrade to
gnumed_v14, one step at a time. This takes too long. Is there a way to create gnumed_v14 directly?
There is no way short of dumping a previously bootstraped database and restoring it.
But the packages does not need to do this. This only needs to be done a single time in the lifetime of an installation. It is not like to bootstrap every day. Trust me. We have some experience from users on Ubuntu. This is no problem at all.
Looks like we can not create/remove databases at all during the installation. That will be left for the user to do.
Anyways in each conf file there is a switch to make it silent. For the time being I would not worry about automatically bootstraping at all. Imagine a user has data and reinstalls. It will potentially overwrite it and the user will be unhappy :-)
If all bootstrapping does is to create databases and import data then we may need to think alternate method for it. Please refer to this: http://lists.fedoraproject.org/pipermail/devel/2011-January/147681.html
Thanks.
I our opionion this is not a huge issue. The packages should install all the files that are neccessary to bootstrap.
Then the user manually runs gm-bootstrap_server.sh which is stored in /usr/bin.
This is it. Works for openSUSE, Debian etc.
Sebastian
I our opionion this is not a huge issue. The packages should install all the files that are neccessary to bootstrap.
Then the user manually runs gm-bootstrap_server.sh which is stored in /usr/bin.
This is it. Works for openSUSE, Debian etc.
I see. In that case it is indeed a easy one. I shall upload the new spec file soon. Thanks.
On Sun, Jan 9, 2011 at 12:53 PM, susmit shannigrahi thinklinux.ssh@gmail.com wrote:
I our opionion this is not a huge issue. The packages should install all the files that are neccessary to bootstrap.
Then the user manually runs gm-bootstrap_server.sh which is stored in /usr/bin.
This is it. Works for openSUSE, Debian etc.
New files uploaded to http://susmit.fedorapeople.org/packaging/gnumed-server
Can you please check? If everything is fine, I shall push it bugzilla, which is a bottleneck and takes most of the time in a package lifecycle.
Thanks.
On Sun, Jan 09, 2011 at 08:18:18PM +0100, Sebastian Hilbert wrote:
Then the user manually runs gm-bootstrap_server.sh which is stored in /usr/bin.
It should be actually in /usr/sbin because you run the script as root. In Debian also the ".sh" extension is removed because the programming language should not be added as extension per Debian policy.
This is it. Works for openSUSE, Debian etc.
Just uploaded GNUmed-server 14.6-1 package :-)
Andreas.
Just uploaded GNUmed-server 14.6-1 package :-)
https://bugzilla.redhat.com/show_bug.cgi?id=669146 I am not sure how long it will take there. Thanks.
Am Mittwoch, 12. Januar 2011, 20:16:08 schrieb susmit shannigrahi:
Just uploaded GNUmed-server 14.6-1 package :-)
https://bugzilla.redhat.com/show_bug.cgi?id=669146 I am not sure how long it will take there. Thanks.
Thank you. I will test it tomorrow.
Sebastian
Am Mittwoch, 12. Januar 2011, 20:16:08 schrieb susmit shannigrahi:
Just uploaded GNUmed-server 14.6-1 package :-)
https://bugzilla.redhat.com/show_bug.cgi?id=669146 I am not sure how long it will take there.
Is there anything that can be done to speed up the process ?
BTW. I have set up FC 14 from scratch and installed gnumed-client and gnumed- server form the opensuse build service repository as a reference.
I am now going to push your spec file to opensuse build service which will build a gnumed-server package from your spec file which can then be tested in my setup of FC14
Have fun, Sebastian
On Thu, Jan 20, 2011 at 7:20 AM, Sebastian Hilbert sebastian.hilbert@gmx.net wrote:
Am Mittwoch, 12. Januar 2011, 20:16:08 schrieb susmit shannigrahi:
Just uploaded GNUmed-server 14.6-1 package :-)
https://bugzilla.redhat.com/show_bug.cgi?id=669146 I am not sure how long it will take there.
Is there anything that can be done to speed up the process ?
Unless some reviewer picks it up, no.
BTW. I have set up FC 14 from scratch and installed gnumed-client and gnumed- server form the opensuse build service repository as a reference.
I am now going to push your spec file to opensuse build service which will build a gnumed-server package from your spec file which can then be tested in my setup of FC14
Well, I have no idea about opensuse build server. You can simply install the rpm from my fedorapeople space and test it for correctness till it get pushed to fedora buildsystem.
Thanks.
Hi Sebastian,
There were a few questions raised for review. Can you please have a look at the bugzilla ticket?
I shall continue improving the spec file in the meantime.
Thanks.
On Wednesday 09 February 2011 15:38:47 susmit shannigrahi wrote:
Hi Sebastian,
There were a few questions raised for review. Can you please have a look at the bugzilla ticket?
I shall continue improving the spec file in the meantime.
14.6 tgz is now there. It was a mistake.
There are a few manpages in the source and Debian ships them as well.
The question about a local server is total nonsense (sorry). The whole point of the package is to bootstrap a local database (for your local medical clinic) and no you do not need a local postgresql. It can be anywhere. The location (ip address) can be changed in the conf files.
Please communicate that this package does nothing more then copy the relevant files which are needed to *create/bootstrap* a database inside an already installed postgresql.
I think the confusion stems from the fact that most of the time packages copy files that are used every time one starts the program. If wanted the package could copy the files, bootstrap the files and remove the files. But come on. think about it.
Please let me know if there is anything to help out further. I will remove the upstream rpm if that helps.
Sebastian
14.6 tgz is now there. It was a mistake.
Thanks.
There are a few manpages in the source and Debian ships them as well.
Ok.
The question about a local server is total nonsense (sorry). The whole point of the package is to bootstrap a local database (for your local medical clinic) and no you do not need a local postgresql. It can be anywhere. The location (ip address) can be changed in the conf files.
I see. So this was one more mistake that I made.
I think the confusion stems from the fact that most of the time packages copy files that are used every time one starts the program. If wanted the package could copy the files, bootstrap the files and remove the files. But come on. think about it.
It's very common for a package to take several mails back and forth to get it to publishing point. :) That's the hardest part. Then it is very easy to maintain it though out the lifecycle then.
Please let me know if there is anything to help out further. I will remove the upstream rpm if that helps.
No, that's not required.
Thanks.
On Thursday 10 February 2011 20:34:05 susmit shannigrahi wrote:
14.6 tgz is now there. It was a mistake.
Thanks.
There are a few manpages in the source and Debian ships them as well.
Ok.
The question about a local server is total nonsense (sorry). The whole point of the package is to bootstrap a local database (for your local medical clinic) and no you do not need a local postgresql. It can be anywhere. The location (ip address) can be changed in the conf files.
I see. So this was one more mistake that I made.
I think the confusion stems from the fact that most of the time packages copy files that are used every time one starts the program. If wanted the package could copy the files, bootstrap the files and remove the files. But come on. think about it.
It's very common for a package to take several mails back and forth to get it to publishing point. :) That's the hardest part. Then it is very easy to maintain it though out the lifecycle then.
I am a friend of doing it right from the start. For outsiders like me there is the impression that the big guys are there to kick you out instead of either asking or helping out.
Thanks for your works. We would not have done it without you.
Sebastian
It's very common for a package to take several mails back and forth to get it to publishing point. :) That's the hardest part. Then it is very easy to maintain it though out the lifecycle then.
I am a friend of doing it right from the start. For outsiders like me there is the impression that the big guys are there to kick you out instead of either asking or helping out.
That won't be too easy. :) However, it takes some time to get everything right.
Thanks for your works. We would not have done it without you.
Thank you!
On Thu, Feb 10, 2011 at 08:24:29PM +0100, Sebastian Hilbert wrote:
I think the confusion stems from the fact that most of the time packages copy files that are used every time one starts the program. If wanted the package could copy the files, bootstrap the files and remove the files. But come on. think about it.
Well, actually I would not consider removing the package (as it is in Debian) as useful because in addition to the SQL files it caries it has some scripts organising backup / restore and stuff like this. If there would be any point in removing the package with the SQL code (which I do not see at all) we should build two packages: One which is up for removal later on and one which has those tools, cronjob entries etc.
Kind regards
Andreas.
Hi,
I was a bit busy last two weeks, so could not work on this. Today I have updated the package and commented on bugzilla for review. It should be fine.
A few questions:
1. I did not find a cron file in the source. It is required? If yes, can you please pass me a sample?
2. There are a few missing man pages. Not a huge deal though.
gnumed-server.noarch: W: no-manual-page-for-binary gm-restore_database gnumed-server.noarch: W: no-manual-page-for-binary gm-zip+sign_backups gnumed-server.noarch: W: no-manual-page-for-binary gm-move_backups_offsite gnumed-server.noarch: W: no-manual-page-for-binary gm-restore_data
3. Is it ok if I replace the directory structure */gnumed/server/* by */gnumed-server/*? So what is in /var/lib/gnumed/server in debian will be in /var/lib/gnumed-server. Do you think this may break something?
Thanks
Hi,
On Sun, Feb 27, 2011 at 08:09:43PM -0700, susmit shannigrahi wrote:
- I did not find a cron file in the source. It is required? If yes,
can you please pass me a sample?
The Debian packaging at svn://svn.debian.org/svn/debian-med/trunk/packages/gnumed-server/trunk/debian contains a cron.daily file - I have no idea whether Fedora is using the same mechanism but you might get an idea what to do.
- There are a few missing man pages. Not a huge deal though.
gnumed-server.noarch: W: no-manual-page-for-binary gm-restore_database gnumed-server.noarch: W: no-manual-page-for-binary gm-zip+sign_backups gnumed-server.noarch: W: no-manual-page-for-binary gm-move_backups_offsite gnumed-server.noarch: W: no-manual-page-for-binary gm-restore_data
I have written some manpages for some scripts and upstream took them over. If you would take over writing the missing ones this would be great.
- Is it ok if I replace the directory structure */gnumed/server/* by
*/gnumed-server/*? So what is in /var/lib/gnumed/server in debian will be in /var/lib/gnumed-server. Do you think this may break something?
I can not imagine any severe breakage - perhaps adjusting pathes in some scripts. Do you see any strong reason for this rename? Do you think the decision for /var/lib/gnumed-server is suboptimal?
Kind regards
Andreas.
On Mon, Feb 28, 2011 at 1:25 AM, Andreas Tille andreas@an3as.eu wrote:
Hi,
On Sun, Feb 27, 2011 at 08:09:43PM -0700, susmit shannigrahi wrote:
- I did not find a cron file in the source. It is required? If yes,
can you please pass me a sample?
The Debian packaging at svn://svn.debian.org/svn/debian-med/trunk/packages/gnumed-server/trunk/debian contains a cron.daily file - I have no idea whether Fedora is using the same mechanism but you might get an idea what to do.
Nice, thanks.
- Is it ok if I replace the directory structure */gnumed/server/* by
*/gnumed-server/*? So what is in /var/lib/gnumed/server in debian will be in /var/lib/gnumed-server. Do you think this may break something?
I can not imagine any severe breakage - perhaps adjusting pathes in some scripts. Do you see any strong reason for this rename? Do you think the decision for /var/lib/gnumed-server is suboptimal?
The reason I did this because fedora packaging naming guideline says: "When naming a package, the name should match the upstream tarball or project name from which this software came.", which, in this case, is gnumed-server and also, I get to use %{name} macro everywhere.
However, packaging guideline also says "If this package has been packaged by other distributions/packagers in the past, then you should try to match their name for consistency.".
So, I am fine with both naming schemes, just need to make a decision which one to use. :)
Thanks. [1] http://fedoraproject.org/wiki/Packaging/NamingGuidelines#General_Naming
On Mon, Feb 28, 2011 at 01:35:35AM -0700, susmit shannigrahi wrote:
I can not imagine any severe breakage - perhaps adjusting pathes in some scripts. Do you see any strong reason for this rename? Do you think the decision for /var/lib/gnumed-server is suboptimal?
The reason I did this because fedora packaging naming guideline says: "When naming a package, the name should match the upstream tarball or project name from which this software came.", which, in this case, is gnumed-server and also, I get to use %{name} macro everywhere.
I agree that this in principle makes sense. (I guess there is a similar suggestion somewhere in the Debian docs).
However, packaging guideline also says "If this package has been packaged by other distributions/packagers in the past, then you should try to match their name for consistency.".
So, I am fine with both naming schemes, just need to make a decision which one to use. :)
I think my decision to use /var/lib/gnumed was drawn in the beginning of my packaging work and if I remember correctly at these times the original tarballs were not even separated. I also might have had some reason that there was also some client data in /var/lib and it seemed logical (at this time) to put both into one dir. This is not really true any more. I think it makes sense to let the GNUmed authors decide what they would consider the most apropriate place and stick to this decision.
Kind regards
Andreas.
I am fine with either.
Karsten
On Mon, Feb 28, 2011 at 01:08:07PM +0100, Andreas Tille wrote:
Date: Mon, 28 Feb 2011 13:08:07 +0100 From: Andreas Tille andreas@an3as.eu To: FedoraMedical medical-sig@lists.fedorahosted.org Cc: Karsten Hilbert Karsten.Hilbert@gmx.net, Sebastian Hilbert sebastian.hilbert@gmx.net Subject: Re: GNumed server packaging. User-Agent: Mutt/1.5.18 (2008-05-17)
On Mon, Feb 28, 2011 at 01:35:35AM -0700, susmit shannigrahi wrote:
I can not imagine any severe breakage - perhaps adjusting pathes in some scripts. Do you see any strong reason for this rename? Do you think the decision for /var/lib/gnumed-server is suboptimal?
The reason I did this because fedora packaging naming guideline says: "When naming a package, the name should match the upstream tarball or project name from which this software came.", which, in this case, is gnumed-server and also, I get to use %{name} macro everywhere.
I agree that this in principle makes sense. (I guess there is a similar suggestion somewhere in the Debian docs).
However, packaging guideline also says "If this package has been packaged by other distributions/packagers in the past, then you should try to match their name for consistency.".
So, I am fine with both naming schemes, just need to make a decision which one to use. :)
I think my decision to use /var/lib/gnumed was drawn in the beginning of my packaging work and if I remember correctly at these times the original tarballs were not even separated. I also might have had some reason that there was also some client data in /var/lib and it seemed logical (at this time) to put both into one dir. This is not really true any more. I think it makes sense to let the GNUmed authors decide what they would consider the most apropriate place and stick to this decision.
Kind regards
Andreas.
medical-sig@lists.fedorahosted.org