LYNX-DEV source size, source reorganization

[Klaus Weide]

On Fri, 29 Aug 1997, Nelson Henry Eric wrote:

> Timid request: can we split the distribution into two parts, the
> "absolutely necessary" and the "peripheral"?  An example of what
> I have in mind is the new bind distribution:
> -rw-r--r--  1 user  1044813 Mar 21 08:19 bind-doc.tar.gz
> -rw-------  1 user   613780 Jul  1 09:51 bind-src.tar.gz
> 
> It is nearly impossible to download any file outside of Japan greater
> than 1MB to my site.  Most downloads time out after 2-3 hours, and it
> usually takes longer than that to download the current lynx.  I cannot
> believe that I am the only one in this predicament.
> 
> Recently I proposed a simplification of the top directory of the lynx
> distribution.  Actually behind my proposal was a desire to have the
> lynx-dev community begin thinking about what really needs to hit the
> viewers eye when he/she first looks at the breakout.  In its present
> state, it's pretty hard to know where to start reading.
> 
> To make my words a little stronger, the entire `util' directory is just
> plain *baggage*.  And, why do I have to download all the chartrans tables
> just to download new source code?  And to get downright nasty so that
> maybe someone will listen: Gee, why don't you put in translation tables
> for CJK (and add another 1MB+ to the distribution)?  Tell me, who reads
> CHANGES2-3, or even CHANGES2-6, for that matter?  Anyone really looked at
> what's in the `doc' directory?
> 
> My point is once you've got it, it's history.  Why waste band space and
> prevent/discourage people from downloading new source code that's just
> dying to be tested?
> 
> Sorry to get rude; I'm totally frustrated over here.

You are mixing several things in this (is it a?) proposal.

First you are talking about "the distribution".  I assume you mean the
currently-not-existing, but to-be-determined form in which a new
"official" lynx "version" shall be distributed.

I am against having a final package which is split in any way, but
especially if it is split along the line of docs vs. code.  Either the
docs are useful and important, then they should always "be with the
source" so the whole thing is consistent; or they are unimportant and
unnecessary, then we can get rid of them.  It takes only one mirrored copy
in Japan to make faster downloading possible, right?

If it turns out that a lot of the not-yet-existing lynx version is
optional stuff (maybe chartrans tables, message catalogs, "historical"
files) - well someone may want to repackage the source distribution
to a "reduced functionality source package" with smaller size.  I don't
think the demand would be high, but I may be wrong.  I don't think it's
a good idea (unless your hypothetical 1MB+ CJK table becomes reality), but
you may disagree.  I don't think the developers should do this.


OTOH you speak about following the development code(s), and your resulting
frustration.  At least I asume that is what you mean -- you wouldn't be
complaining so much if you only had to download what you regard as too
much every time a new "official version" comes out, would you?

Well, if you want to follow the development code, just get the diffs from
<URL: http://sol.slcc.edu/cgi-bin/lynx/patch>!  Get them in compressed
form!  I don't really know how we can make it more convenient for you to
get only what's needed.  I was specifically thinking about your situation
when we put the compression stuff in the patch-o-matic script.

The files are also accessible in a breakout under <URL:
http://sol.slcc.edu/lynx/current/lynx2-7-1/>.  You can get a list of
changed filenames only from the patch page, if you want to download
selected files manually.


Thirdly, you write about reorganizing the directory structure for
documentation, as I understand it.  I agree that it may be hard to know
where to start reading, especially with the current development code.
One idea is to reduce the number of files in the top directory,
another is to make sure that, wherever one starts reading, one is
pointed to the right files that need to be read.  I don't like to make the
judgement calls here, in fact I would prefer to completely stay out of 
this if possible :).  Someone should make a complete proposal, with the
necessary edits, then if there is some agreement and no strong and valid
objections we could try it out with the development code package.

You sent your diffs for userdefs.h a while ago, which splits out the
anonymous stuff from userdefs.h.  I don't know wheter it it is a good
or bad idea.  It adds to the clutter in the top directory (one more
file), but makes it easier to go through userdefs.h for those who
don't need to make changes for anonymous accounts.  (Any advantages I
have missed?)  So if there is general applause for this idea and no
good reasons offered for not making this change, I'll make the change
in the development code, otherwise I won't :)

You also wrote then:
> As for reorganizing the top level directory I could send the script
> I use to mv things from about_lynx to help (renamed from lynx_help),
> rm -r about_lynx, rm some stuff in docs and mv old CHANGES, *.announce,
> etc. there, rm -r util/inews, and some other minor simplifications, but
> it seems so trivial.  I could do the diff for lynx_help_main.html.

If that script shuffles files around so that they end up being in
places where they should be, and that applies for everybody, then it
would be better we just put them in the right places so they won't
need shuffling around.  The 'rm' is probably only useful for a few
people - those who keep there source directories around after
compiling and installing.  You do it, and I do it, but I think we are
the exception.  Another case where 'rm' those files could be useful is
for some people with really limited disk space, before compilation, if
it just happens that with those files there is not enough disk space
for compiling, but after removing there is enough space.  I don't
think that happens frequently.  A new makefile target for this may be
more appropriate than adding a script.

I am not sure what diffs for lynx_help_main.html you mean.  (Was that
related to the script?)  If there's something which should be there but
isn't, and you have written something up, sure send the diffs :)


       Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;