Re: Comments please

[Rick Jones <rickya@siservices.net>]

George Bonser wrote:
> 
> 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.

That is the problem with the dependancies I was refering to. 
Reguardless of that problem being fixed or not, it is a black mark on
Debian's record and I don't think we should stigmatize our distro by
saying we are using it.  If we do use it, I assume you mean the handling
methods not dselect, we would ofcourse include a statement in the readme
or whatever that it is based on Debians dpkg etc.

I'm not at all against using dpkg, with the dependancies fixed.  I am
just aprehensive of prominantly displaying that given that it does have
a bad reputation, even if it is an exagerated reputation.

> 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 last I heard from Bruce was that he wasn't promissing anything, but
would "give us a shot...don't blow it."  While that isnt't flat out
refusal, it doesn't sound like an "effort" on their part.  Sounds like
they might if it suits them.  I have nothing against Bruce, or Debian. 
I have used Debian for over 2 years and am pleased, for the most part,
but given that Bruce posted that when a discussion about the
"cooperative effort" was going on in the list, I tend to think he was
letting us know that some of us were reading a bit too much into the
cooperation.  If it looks like a duck and quacks like a duck....

I absolutely agree.  My impression from your doc was that we, basically,
won't make a move without Debian.  I'm saying we shouldn't have to do or
not do anything because Debian does.  If that is not what you meant to
convey in the doc, it might be of use to you to know it can be perceived
that way.

> The last thing the world needs, in my opinion, is yet another incompatable
> linux distribution. 

SEUL's goal is to be _a_ leader in the cause to standardize Linux
distro's.  We should standardize things efficiently.  That makes it
attractive to others to follow and vendors to endorse.  If that is
Debians way, so be it.  If it's not, so be it.  The idea isn't for us to
jump in line with the best of the worst but to select the best of all
and make it easy for all to base their distro on.  Since we are aiming
at standards there is no way we are going to be "incompatable".

Remember, we are trying to lead, not follow.  The good aspects of Debian
are going to augment SEUL, along with any other distro with good
aspects.  At this time Debian good out weighs it's bad by a larger
margin than the rest and therefore we use it as a base reference.

> 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.

Right here is what I'm saying about us not being a Debian diff.  You say
that "Debian packages" may be maintained by SEUL maintainers but "Debian
maintainers" *might blend* our *ideas* into "their work".  That makes us
sound like an extension of Debian, rather than a seperate distro working
in common with Debian to standardize Linux and produce a long needed
user-friendly distro.

The way you refer to SEUL is more as an augmentation *to Debian* than
it's own distro taking the good ideas from another distro to make a
better, seperate, distro.  Whether you mean to or not you make it sound
that way.

> 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.

This is the purpose of SEUL.  To do it better and make it appeal to the
other distros to follow our lead.

> 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.

Ofcourse.  That is what the GPL assures.  There is no need for you to
point out the obvious.

> 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. 

It is required under the GPL to supply the source *or* be able to point
a user to the source if they want it.  Not that I dissagree with
archiving it ourselves, but that wasn't my point.

> 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.

What you're saying here is that our developers aren't trusted to QC the
source.  I seriously doubt that Bruce sat up every night QCing compiling
and packaging over 2000 packages.  I've browsed the incoming at Debian
and they are deb files.

> 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.

Again.  I am not talking about Debian packages specifically.  Where does
the GPL specify that anybody has to make a dif to the original source?

> 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.

I hate to get off on a tangent, since this is not my point, but which
GPL are you talking about?  I have never d/l'd a tarball that had a diff
in it for each person that modified it since the original.  I have never
seen a GPL that said you had to do that either.  It only talks about
including the original authors copyright and disclaimer along with
honorable mention, basically.  Nothing about keeping source seperated
into diffs and such.

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

All that is "required" by the GPL is that the source is *available* to
the user.  It doesn't matter if it's on our site or the originating site
if the "source" is unchanged.  

Again.  My point isn't whether or not we archive the source for the
user.  It's probably best if we do.  My point is that there is no reason
why a person can't *add* a script that improves the software from an
end-users standpoint that *doesn't* modify the original product, and
submit that in a binary package.  If we want to archive the source, as
you are saying, then that same user can just transfer the original
tarball from the programmers site to the SEUL archives in addition to
the binary package.

> 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.

No diff.  There isn't always going to be a diff.

If I go out on the net and get some app that Debian doesn't have but
will be good for our target users, and I get that pre-compiled by the
orignating programmer, and write up a few scripts to make it easy for
the end-user to configure/install and maybe add an alternate in
/etc/alternates for compatability, I should be able to upload that
binary package to the archives, with the original source and my scripts
packaged seperately.


That will make life easier for everybody since the compiling will not be
done by the same one, or two people.  We are talking about thousands of
packages.

-- 
Out here,

Rick Jones
rickya@siservices.net
===
SEUL-Leaders list, seul-leaders-request@seul.org
===