[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Conquest approaching upload state



Hello,

On Wed, Mar 12, 2014 at 01:40:08PM +0100, Andreas Tille wrote:
> 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.

I imported it again with --pristine-tar option now and pushed --all.

> Once this is donw I could have a look at your packaging (if nobody beats
> me in this ... which would be even prefered).

I'd be glad if you could check it. But mainly, I need feedback on the two
issues I raised in the first email about the main binary placement and
ownership (see below).

Thanks for your time.

Pablo

> 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


Reply to: