Re: [MoM] Update on packaging of OpenEMR
Andreas - Am working on getting the latest devscripts distro. I have
2.14.1 from Ubuntu but I think that mk-origtargz is actually from
2.14.2 or later. Will be a day or two for me to figure out if I
should just switch to a development version of Debian or <gulp> jump
on the unstable development branch in Ubuntu. Probably will need to
be a virtual machine with a Debian version.
More once I have that going ...
cheers
ian
On Mon, Jun 23, 2014 at 11:28 PM, Andreas Tille <andreas@an3as.eu> wrote:
> 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
>
>
> --
> To UNSUBSCRIBE, email to debian-med-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 20140624062819.GB6539@an3as.eu">https://lists.debian.org/[🔎] 20140624062819.GB6539@an3as.eu
>
--
Ian Wallace - CCRMC DFM Staff Physician - (c) 303.681.5732
Reply to: