Re: Comments please

[George Bonser <grep@oriole.sbay.org>]

On Tue, 27 Jan 1998, Rick Jones wrote:

> I don't think a description of Debians package tool fit's in context of
> the document.  Not to mention that the SEUL package tool hasn't been
> decided yet, that I know of.  Anybody who's tried Debian and gave up
> because they couldn't get past the depends trouble during install is
> going to cringe away from SEUL.

Well, we are going to be using the debian packaging system. An integral
part of that system as well as RedHat's rpm is the concept of
dependancies.  How those dependancies are handled when there is a conflict
is the real issue.  With Red Hat's system, you only discover the
dependancy when you attempt to install the package, Debian's method gives
you the luxury of finding out about the conflict the second that you
select the package.  

> 
> I don't agree on the package upgrading you've outlined.  I don't think
> we should remain connected at the hip with Debian once we have SEUL
> going.  It should take it's own road.  

The last I heard from the project leadership, it is to be a cooperative
effort.  Debian has resources that can be very useful and, in turn, we can
be a very useful resource for Debian. I do not see why they can not adopt
a  better installer or package defaults from SEUL if they wish. 

> 
> The SEUL -> Debian, Debian -> SEUL, Debian <- SEUL, will be more trouble
> than it's worth.  It will make us look like we are a Debian package.  It
> means we would only need to be a diff outlet for Debian users.  We
> should just build our own packages and have that be that.

The last thing the world needs, in my opinion, is yet another incompatable
linux distribution. It is quite possible that a good many of Debian's
packages could be maintained by SEUL project members at some point in the
future.  By the same token, some of Debian's package maintainers might
actually like what we are doing and blend our ideas into their work.
Debian gives us an economy of scale ( not in dollars so much but in
potential user base and number of developers ) that would take a long time
for us to develop on our own.  Sure, maybe we will diverge so far as to be
completely unrecognizable from Debian but if our ideas are really good
ones, I suspect that Debian will adopt a good many of them and therefore
we will not really diverge as far as we might.  You must remember that
since our work will be free and based on the Debian packaging system and a
cooperative effort with Debian, they will be free to adopt our programs
and methods or not as they choose.

> 
> The "NO BINARIES" is a problem also.  Many of us have been qouted as
> saying "let's not try to reinvent the wheel".  Along those same lines I
> see no reason to obtain the source for a package I might get in binary
> form and configure for SEUL's file system, look and feel.

It is required by the GPL to provide source. Debian's model is to provide
the pristine source and their diffs against that source as a separate
bundle. In addition, it is protection for our users. Think of it as both a
security and a stability feature. Since the pristine source is obtained
from the official archive, there is less chance of malicious fiddling with
that source by someone. The diff against that source is scrutinized as a
sanity check. We need to make sure that no obvious security holes are
inadvertently created and that the package does things according to
policy. The package in then compiled on a reference machine to provide
stability. After testing, the source, diff AND THE RESULTING BINARY
package are placed on the FTP site for download.  Binary packages will not
be accepted for UPLOAD but most customers will be downloading the
resulting binary package.


 
> I should be
> able to do this, package it and send it to the archives.  I shouldn't
> have to get the source, modify the Makefiles and possibly the source
> itself so that it's in the condition to compile and install when all I
> wanted to do was add a shell, dialog, or newt script etc. to it.  

You could submit a diff to the debian package.  That is completely
acceptable. In other words, you download the source, apply the debian
diff, make your changes, create a new diff.  Your changes MUST be
available in either source form or as a diff to the source according to
the GPL.

> 
> Besides that, who among us is going to want to compile and install every
> package to make sure it's working in finished form before packaging it
> in binary for release?

Unfortunately, we HAVE to do that for every package that we change. That
is one of the benefits of working with debian, we can accept many of their
packages as-is trusting THEM to have already done that for us.  Every
package that we change is going to have to be compiled and tested if for
no other reason than to be sure that we are in compliance with the GPL and
that the source we provide is, in fact, what gets generated when the
source is compiled.  You can only provide binaries as long as you also
provide the source that was used to create it.  Any modifications to the
original source must be provided as a requirement of the GPL.

> 
> In keeping with the GPL, I would agree that the original source has to
> be included with the package, but not as the package.

The package uploaded from the SEUL developer is source.  SEUL creates the
binary and that is what is downloaded by the user.

> That just closes
> the doors for users that can't modify code that want to maintain a
> specific package for SEUL.  I really don't know for sure, but I would
> find it hard to believe that Debian requires this either.

Ah, I see. Basic misunderstanding here ... the user never sees the source
unless they want it for some reason, the developer UPLOADS the package as
a diff against the original source. The user downloads binary packages.


George Bonser 
If NT is the answer, you didn't understand the question. (NOTE: Stolen sig)
http://www.debian.org
Debian/GNU Linux ... the maintainable operating system.

===
SEUL-Leaders list, seul-leaders-request@seul.org
===