Thread: 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/