GNumed server packaging.

[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:

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/

[Sebastian Hilbert]

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

[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.

[Sebastian Hilbert]

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

[susmit shannigrahi]

> 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.

[susmit shannigrahi]

On Sun, Jan 9, 2011 at 12:53 PM, susmit shannigrahi
 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.

[Andreas Tille]

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.

[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.

[Sebastian Hilbert]

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

[Sebastian Hilbert]

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

[susmit shannigrahi]

On Thu, Jan 20, 2011 at 7:20 AM, Sebastian Hilbert
 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.

[susmit shannigrahi]

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.

[Sebastian Hilbert]

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

[susmit shannigrahi]

> 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.

[Sebastian Hilbert]

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

[susmit shannigrahi]

> > 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!

[Andreas Tille]

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.

[susmit shannigrahi]

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

[Andreas Tille]

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.

[susmit shannigrahi]

On Mon, Feb 28, 2011 at 1:25 AM, Andreas Tille  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

[Andreas Tille]

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.

[Karsten Hilbert]

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 
> To: FedoraMedical 
> Cc: Karsten Hilbert ,
>    Sebastian Hilbert 
> 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.
>
> -- 
> http://fam-tille.de