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

Re: Multipart package (IRAF)



-----BEGIN PGP SIGNED MESSAGE-----

On 18 Feb 1998, Manoj Srivastava wrote:

> 	I think we have to compile it and make sure there are no bugs,
>  since Debian is no longer single architecture, and 2, from the policy
>  manual:

>         * must not require a package outside of "main" for compilation or
>           execution (thus, the package may not declare a "Depends" or
>           "Recommends" relationship on a non-main package),

    This may or may not be a problem, since the distributions from
NOAO have been _per-architecture_ and I'm not entirely sure how to deal
with it.  The addon packages (the replacement for SAOImage and the xgterm
stuff) are much better behaved, and have been split off from the main
distribution with Imakefiles.  However, I *can* package the other static
binary packages for the other architectures they have pre-supported.


>         * must not be so buggy that we refuse to support them,

    Not a problem.  As distributed, the program has been behaving very
well for me, but I'm running the static binaries at the moment.  (I have
lots of disk space).


> 	I can't see anything in policy that states we can't use
>  precompiled binaries+source, but I think if the package is so buggy
>  we can't even compile it, we should not be distributing it.

    It's not that it's buggy...  it's that it's not using what I would
call the "standard" form of compilation.  This package is HUGE, and
somewhere in the writing of Makefiles for everything I have a sneaking
suspicion that I'm going to screw something up.  To recompile the system
normally, you run a statically linked program on a source directory
(something like make-kpkg, except it's not a script I can read)...
Which I'd be happy to simply script into a Makefile except that the file
used to compile is one of the binaries...


> 	Also, I think source packages should not contain binaries at
>  all, and that too binaries for just one architecture.

    I'd love to agree with you, but I'm not sure how to pull it off.


> 	In my opinion, this package does not belong in Debian unless
>  we can actually compile it. Technically, we are also supposed to look
>  at the source code and assure ourself that it does not contain a
>  trojan horse or any other major security nono.

    Oh I can compile it.  I just can't do it without a precompiled
provided binary.  And as far as looking through the source codes for major
security nonos, well, I've thumbed through sections while I was looking
for the reason for a problem I ran into during my initial install (the
install manual sucks :), and didn't see anything sensitive...  But there's
probably a good 30 megs of source alone in there and I'm obviously not
going to catch anything spectacularly obvious.  How would you like to
check Emacs for a security hole :)
    Also, FWIW, the entire system is owned and run as user iraf, group
nogroup (has to be created on the system).  No setuid binaries, and in
fact no binaries even owned by root.


>  Though I have not looked at all the source code for my packages, I
>  have skimmed it all, and I pay close attention to the upgrade diffs
>  each time. I am luck to be maintaining packages that are quite
>  popular, and hence come under a great deal of scrutiny.

    Actually, IRAF is also pretty popular, but moreso with scientists than
with hackers, and so not by people who could place the *code* rather than
the functionality under scrutiny.  Still, Linux itself is well enough
designed that I don't think a userid-run and owned program can actually
do all that much damage.

    It's a little frustrating, because after having used Slackware and
Redhat, I'd like to see Debian become very mainstream, and the more
major packages get added to it, the better.  I've got 22 packages in
my local/binary directory that I created for my own system, not
including IRAF, but until the libpthreads problem gets resolved, I
can't go up to hamm to make them official.

    As a subthought -- what's the policy on starting a package in
contrib and moving it to main at a later date?  I could get the
initial stuff wrapped up, and if I manage to get everything into a
- -buildpackage recognizable form I could up the Debian subversion by
one and move it to main at that time.

=============================================================================
Zed Pobre  <zcp@po.cwru.edu>  |  PGP key on servers, fingerprint on finger
=============================================================================

-----BEGIN PGP SIGNATURE-----
Version: 5.0
Charset: noconv

iQEVAwUBNOr81NwPDK/EqFJbAQEA9Af/ZDGLr9voloP6ZjxmsxIyt8q5wnSrt1Wv
eEhqGxK+mIFLBEuG7h2CqooYI73s0yYar9rcCYwNXsd3bd6XW/2IjN3zS31uaDQT
7MfEoKz+3HVOfOxlTzbTmhS19yk+J22N7/husJu876E4A+ECVkIn4emZT1GKhA2y
Ypp+ow8Iv8E1QUaIXkJBvWevLjFBwXz+lMYO5m15gb5hHr+Y4f6Fx/lU103kT9Gv
pgcr74UIVWnjcdX0puTRBPjWbBq5dmIdivO141FyNaMfZlvmAFWVnlD34pdTYwgz
VsIPCUhxtQ+MwdjGrclrtN8EXg8ky9VzBj0Kvd53Nlmg/4oxVAE4Dw==
=TfK6
-----END PGP SIGNATURE-----


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: