Re: Conquest approaching upload state
Hi Pablo,
thanks for your work on this package.
I wanted to check your packaging but did not found any pristine-tar
branch as it is requested by Debian Med policy[1]. So you either forgot
to use the --pristine-tar option in the suggested
git import-orig --pristine-tar <upstream-tar>
call or you forgot to `git push --all`. If the first is true you can
easily repeat the step above and simply ignore the warning that the
upstream tag just exists.
Once this is donw I could have a look at your packaging (if nobody beats
me in this ... which would be even prefered).
Kind regards
Andreas.
[1] http://debian-med.alioth.debian.org/docs/policy.html
On Tue, Mar 11, 2014 at 04:28:48PM -0300, Pablo Lorenzzoni wrote:
> Hello ALL,
>
> I am quite happy with the packaging so far and I am about to bring it all to
> a state where I can upload it to archive. My first intention was to upload a
> dicom-server only package, as I wrote in README.Debian, but I am considering
> uploading the CGI interface along with the package... I have at least 2
> considerations regarding that:
>
> (*) Main Binary placement
>
> The main binary (dgate) acts as a daemon, as a command-line interface and as
> a CGI interface. There seems to be no optimal solution for where to put it:
>
> (1) Either I put dgate binary in /usr/bin/dgate where daemon and command-line
> interfaces can live, but not CGI interfaces.
>
> (2) Or I put it in /usr/lib/conquest-dicom-server where CGI interfaces can be
> but is an awkward (but OK) place for a daemon and a really ugly place for a
> command-line interface.
>
> (3) Or I put it in /usr/lib/cgi-bin/conquest-dicom-server where it's super
> for a CGI interface but really ugly for daemon and command-line.
>
> (*) Ownership
>
> Webapps should generally be owned by www-data user and group. Right now, all
> files are owned by an unprivileged user (not www-data). While running as a
> CGI-interface, for instance, if owned by www-data, the binary would not be
> able to access the configuration file (at least not the same configuration
> files that the daemon is accessing). I can't think a way around that, unless
> using some permission trickery or maintaining two sets of config files, both
> with unpleasant consequences.
>
> What are your thoughts on that?
>
> []s
>
> Pablo
>
> --
> Pablo Lorenzzoni (Spectra) <spectra@debian.org>
> GnuPG: 0x268A084D at pgp.mit.edu/keyring.debian.org
> This message is protected by DoubleROT13 encryption
> Attempting to decode it violates the DMCA/WIPO acts
>
>
> --
> To UNSUBSCRIBE, email to debian-med-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 20140311192847.GF4596@erebor.spectra.zapto.org">https://lists.debian.org/[🔎] 20140311192847.GF4596@erebor.spectra.zapto.org
>
>
--
http://fam-tille.de
Reply to: