[task #4901] Reorganize download directories.

[Derek Robert Price]

Follow-up Comment #2, task #4901 (project cvs):

> I beleive I would like to have the binaries also
> split between stable and feature.

Ok.

> Also, I suspect a need to distinguish binary releases on
> some operating systems as to 32bit or 64bit (solaris & hp/ux)
> and with GNU/Linux there will possibly be a dependence on
> which glib is being used. I do not know if the 32bit files
> should be mixed with the 64bit versions or not.

I assumed that could be part of the platform poriton of a host triplet when
necessary: e.g. amd64.

> Could you come up with the concrete example pathnames you
> want to use for the next release of stable and feature as
> an example?

How about:

top/source/stable/1.11.22/NEWS
top/source/stable/1.11.22/README
top/source/stable/1.11.22/cederqvist-1.11.22.html.bz2
...
top/source/feature/1.12.14/NEWS
top/source/feature/1.12.14/README
top/source/feature/1.12.14/cederqvist-1.12.14.html.bz2
...

> top/binary/stable/unix/solaris/intel/9/cvs-1.11.22-sol9-intel-local.gz
> top/binary/stable/unix/solaris/sparc/9/cvs-1.11.22-sol9-sparc-local.gz
> top/binary/stable/unix/solaris/intel/10/cvs-1.11.22-sol10-intel-local.gz
> top/binary/stable/unix/solaris/sparc/10/cvs-1.11.22-sol10-sparc-local.gz
> top/binary/stable/unix/macosx/10.3/cvs-1.11.22.dmg

This looks like too much detail to me.  The download area was actually
organized like this once, but the sporadic nature of binary contributions
meant that x86-sunos-9 might have a 1.11.19 and x86-sunos-10 might have
1.11.21.  To find the latest one that worked on a given system often meant
clicking around through several directories which might contain compatible
binaries.

I would therefore prefer leaving off as much information in the path as
possible, when possible.  I also wouldn't expect us to get so many platforms
that we'll have unusable clutter without subdividing UNIX.  In this case,
that would mean:

top/binary/stable/x86-sunos/cvs-1.11.22-intel-sunos-5.9.gz
top/binary/stable/x86-sunos/cvs-1.11.22-intel-sunos-5.10.gz
top/binary/stable/sparc-sunos/cvs-1.11.22-sparc-sunos-5.9.gz
top/binary/stable/sparc-sunos/cvs-1.11.22-sparc-sunos-5.10.gz
top/binary/stable/sparc-sunos/cvs-1.11.22-sparc64-sunos-5.10.gz
top/binary/stable/darwin/cvs-1.11.22-darwin-5.5.gz

The rule of thumb for creating a new directory should be binary
compatibility, I think, ignoring backwards compatibility.  So, even if Sparc
Solaris 10 binaries won't run on Solaris 9, it is okay to group them with the
Sparc Solaris 9 binaries since Solaris 9 binaries run on Solaris 10. 
Similarly for 64 bit binaries.  IIRC, when Sparc went to 64-bit UltraSparc,
the 32 bit binaries would still run on the 64-bit machines, so it would be
okay to group the 64-bit and 32-bit binaries here.

> I don't know if the .zip files compatible with Microsoft
> Windows NT/2000/XP/2003 et all whould be listed under
> win32 or woe32...

Hrm.  That's a good question.  Though I'd like to get the woe32 thing across
to a large number of people, not having a "Windows" or "Win32" directory
would probably generate a lot of user confusion.  How about an "x86-woe"
directory with a symlink from x86-windows?  If 32/64 bit binaries become an
issue, we could use x86/64-woe.  Do we need to worry about 95/98/ME
separately?

> I am less certain what to do about the various GNU/linux
> distributions. Is it enough to create a .src.rpm and .i386.rpm
> for those that like RPMs (Redhat, Fedora, SuSE et al)
> and let the debian folks create their own packages?

If someone contributes them, I have no problem including them.  Perhaps these
do deserve RPMS, SRPMS, DEB, etc. subdirectories under x86-linux.  We could
leave it flat for now and reorg it again later if its starts looking too
cluttered, though that may mean updating webpages with links, so maybe it is
better to make those subdirs now?

> I believe we also need to discuss how to make available
> any customized development tools available... if we even
> still have any.

We don't have any currently, but what about a "top/development" directory for
this when it is needed?

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?func=detailitem&item_id=4901>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/