Re: [MoM] Update on packaging of OpenEMR
Hi Ian,
On Mon, Jun 23, 2014 at 03:57:14PM -0700, Ian Wallace wrote:
> > The Files-Excluded field in debian/copyright works when you *obtain*
> > (create) the tarball via uscan (or mk-origtargz which is called by uscan
> > and can be used to test your Files-Excluded field without the need to
> > fetch the upstream source from the web over and over. I have added a
> > get-orig-source target to debian/rules which is described in the
> > developers reference as a target you should use if simple uscan is not
> > sufficient. So you can
> >
> > debian/rules get-orig-source
> >
> > now. The problem is that your patch levels are not really downloadable
> > from sf.net - so uscan can not work like this. So if you have any other
> > means to download openemr-4.1.2p7.tar.gz you could verify the
> > functionality fo Files-Excluded via
> >
> > mk-origtargz --repack --compress xz <path_to>/openemr-4.1.2p7.tar.gz
>
> Is the true solution here to ask the upstream maintainer (Brady) to
> essentially issue a new tar ball with each patch? Would that be a
> more Debian method of doing this?
Strictly speaking yes, if we would talk about packages that would be
prepared for an upload. I also have no idea whether these patches are
just marking some development status or whether these are intended to be
used in production. In the later case I would recommend to provide
these tarballs in any case independently from our packaging attempt. We
are currently in the first development phase so it might have some
profit for you to get a grip on "not so official" code to prepare a
final release and I think it is OK to work with certain patch levels.
But uscan and Files-Excluded which is regarded by uscan only work on
released tarballs which I tried to explain above.
> Then uscan would find the
> openemr-4.1.2p7.tar.gz file on sf.net and could be used to create the
> new orig tar? I'll try the above command to test my Files-Excluded in
> the copyright - I have been creating from scratch using 'tar zcvf'. I
> was worried that the way I was doing it was incorrect (I removed
> 'phpmyadmin' directly from the git repo and then just committed the
> changes which from what you are saying isn't the correct method I
> should always start from the original source tar ball).
Well, I'm hesitating to address one method as "correct" and an other one
as "wrong". Files-Exclouded is working on tarballs and I personally
prefer working with this since it is an established method (well,
working with tarballs is established, Files-Excluded is quite new).
There are alternatives to work with upstream Git repositories and
Charles Plessy is using this in a few packages for certain reasons.
However, this method is totally orthogonal to the Files-Excluded field
in debian/copyright. In short: If you want to use the later you need a
tarball - either from upstream or you might fake one and use
mk-origtargz as written above.
> I tried a
> second method of creating a large quilt patch to just remove
> everything but phpmyadmin has binary files that quilt doesn't like to
> handle.
A quilt patch is NOT the method to remove files from a tarball. The
binaries without source would simply remain in the tarball and just
become invisible in the build process. So this is definitely not the
solution (but remaining a nice training for using quilt anyway ;-)).
> > when beeing located in the root of your Git repository. This should
> > create a file
> >
> > ../openemr_4.1.2p7.orig.tar.xz
> >
> > which you could import via
> >
> > git import-orig --pristine-tar ../openemr_4.1.2p7.orig.tar.xz
> >
>
> Once I test the above creation of the orig.tar.xz I will add to the
> repo so that you can rebuild/test if you have time/want to.
OK.
> > BTW, this would also be needed to enable me reproducing your work since
> > there is no such information in the pristine-tar branch to enable me
> > reproducing your current source tarball.
> >
> > > Just to recap here's where I am:
> > > 1) Can create a deb file that will install/remove.
> >
> > Good.
> >
> > > 2) Webserver currently needs to be manually configured with a2enconf and
> > > service apache2 reload but the default configuration is packaged.
> >
> > Sounds reasonable.
> >
> > > 3) Maintainer scripts (pre/post/inst/rm) have been disabled (Brady Miller
> > > wrote the originals) and I need to wade through them now fixing the various
> > > complaints that linitian generates about unsafe temp files, not using the
> > > template system correctly, not using the PO stuff for internationalization.
> >
> > OK, just report any problems here.
> >
> > > 4) The large project left is finding/updating all of our minified JS. I
> > > confirmed with upstream that in fact the project *does* rely on several
> > > versions all the way back to 1.2.1 of jQuery and the scripts that rely on
> > > it are known to break if updated.
> >
> > Uhm. :-(
>
> I checked on this explicitly to try and determine how many versions of
> the libraries we actually used. I will have to take this on as a pet
> project to update/test and submit patches so that OpenEMR can start to
> use the more recent versions of jQuery. They also use lots of the
> sub-projects (jQuery-ui, and some other ones). I might add some of
> the original source files in the mean time since this will be the
> faster of the two options ... I realize it's duplicate code and should
> be removed but that will be many, many months.
I agree that we should try to find some compromise between a totally
clean implementation and something we and our users could start working
with. There will be some period of time when we need to work with those
duplicates and remove them step by step over time.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: