Обсуждение: FTP server cleanup suggestions

Here are a couple of ideas to make the hierarchy on the FTP server a bit more
understandable and cruft-free:

The doc/ directory only contains outdated material.  If we want to keep it, it
should be moved in the directories of the respective source code
distribution.  For example, move doc/7.3 to source/v7.3/doc.

The files in NT_Support_Files/ are no longer relevant for the Cygwin port and
should be removed.

The old/ directory just contains garbage and should be removed.

README.v7.4.3 should be removed, since 7.4.5 is the latest version.  Same with
the 7.4.3 symlink.

What does the sup/ directory contain?

The win32/ directory should be moved to the binary/ directory.

The substructure of the binary/ directory seems to change with every minor
release.  We should think of a reasonable structure and stick with that.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

> -----Original Message-----
> From: pgsql-www-owner@postgresql.org
> [mailto:pgsql-www-owner@postgresql.org] On Behalf Of Peter Eisentraut
> Sent: 19 October 2004 09:52
> To: pgsql-www@postgresql.org
> Subject: [pgsql-www] FTP server cleanup suggestions
>
> Here are a couple of ideas to make the hierarchy on the FTP
> server a bit more understandable and cruft-free:
>
> The doc/ directory only contains outdated material.  If we
> want to keep it, it should be moved in the directories of the
> respective source code distribution.  For example, move
> doc/7.3 to source/v7.3/doc.

Yup.

> The files in NT_Support_Files/ are no longer relevant for the
> Cygwin port and should be removed.

Yup.

> The old/ directory just contains garbage and should be removed.

Yup.

> README.v7.4.3 should be removed, since 7.4.5 is the latest
> version.  Same with the 7.4.3 symlink.

Yup.

> What does the sup/ directory contain?

Dunno, but it's very old and sup.postgresql.org mentioned in the readme
doesn't exist in DNS any more.

> The win32/ directory should be moved to the binary/ directory.

Currently there is no appropriate directory under binary as there are
only released versions there. I added that symlink in anticipation of
lots of 'where's the pginstaller?' questions - I agree it should
eventually be in binaries, but put it there for now to avoid any
unnecessary faqs from ppl too lazy to think about it.

> The substructure of the binary/ directory seems to change
> with every minor release.  We should think of a reasonable
> structure and stick with that.

Hmm, not pretty is is? What about something like

8.0.0/
  SRPMS/
  fc1/
  fc2/
  redhat9/
  slackware9/
  slackware10/
  suse9/
  win32/
  win64/

With each directory created as required of course.

The patches directory seems a little redundant to me as well.

README.mirrors is incredibly out of date.

Regards, Dave.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

On Tue, 19 Oct 2004, Dave Page wrote:

>> The substructure of the binary/ directory seems to change
>> with every minor release.  We should think of a reasonable
>> structure and stick with that.
>
> Hmm, not pretty is is? What about something like
>
> 8.0.0/
>  SRPMS/
>  fc1/
>  fc2/
>  redhat9/
>  slackware9/
>  slackware10/
>  suse9/
>  win32/
>  win64/

What about:

  8.0.0/
   Windows/
    Win32/
    Win64/
   Linux/
    SRPMS/
    RPMS/
     Fedora/
      Fedora Core 1
      Fedora Core 2
      ...
     RedHat/
      Red Hat 9
      Red Hat EL 3
      ...

Regards,
- --
Devrim GUNDUZ
devrim~gunduz.org                devrim.gunduz~linux.org.tr
             http://www.tdmsoft.com
             http://www.gunduz.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFBdN5ntl86P3SPfQ4RArGoAJ0b6lhXsrFt/QVM/tf4gHGES7zZtQCg05N/
Ak5GbdKW902vdztrerbtclw=
=7w+J
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

On Tue, 19 Oct 2004, Peter Eisentraut wrote:

> The substructure of the binary/ directory seems to change with every minor
> release.  We should think of a reasonable structure and stick with that.

I think I'm responsible for the latest minor release directory structure
changes. While building the RPMS, I've used my own directory structure on
my local disk...

Regards,
- --
Devrim GUNDUZ
devrim~gunduz.org                devrim.gunduz~linux.org.tr
             http://www.tdmsoft.com
             http://www.gunduz.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFBdN7Ytl86P3SPfQ4RAhBjAJsHS6OQJiXUYGmqgswhJJlRMXv9rwCdHzNS
bJ88twwu6inceP761f5Q1QU=
=lO3d
-----END PGP SIGNATURE-----

Dave Page wrote:
> Hmm, not pretty is is? What about something like
>
> 8.0.0/
>   SRPMS/
>   fc1/
>   fc2/
>   redhat9/
>   slackware9/
>   slackware10/
>   suse9/
>   win32/
>   win64/

I think it would be most efficient to list the general operating system
as the top-level, and then organize the operating system versions below
that.  The reasons are first that some operating systems have a lot of
releases that would crowd out the other ones, the other is that in some
cases the maintainers may wish to set symlinks (e.g., because sles9 and
suse91 are binary compatible) or share a common source or otherwise
organize the files more efficiently, which is better not done at the
top level.  So for example:

8.0.0/
  fedora/
  redhat/
  slackware/
  suse/
  windows/

--
Peter Eisentraut
http://developer.postgresql.org/~petere/