The ftp server can then submit a list (and structure) of which platforms
are supported for yum downloads, which can then later (in a separate
commit) be used to generate a nicer download for yum repo rpms.
This change properly handles symlinks by expanding any it finds in the path
and issuing a redirect to the canonical location.
Whilst we're here, display links as such on the pages, sort directory listings
so the parent link is always at the top, and avoid unnecessary redirects caused
by missing /'s on URLs.
This one will validate that the url is under /accounts/, which is
the only part we are going to be excluding from caching once we
move the website to https-only.
The manifest URL (which is optional) will point to an XML file that
describes the command line, option file and environment options that
can be passed to an installer, to allow automated or non-interactive
deployment tools to figure out what info is required to run an
installer and how to pass it to it.
Requires SQL:
ALTER TABLE downloads_stackbuilderapp ADD COLUMN manifesturl character varying(500);
UPDATE downloads_stackbuilderapp SET manifesturl = '';
ALTER TABLE downloads_stackbuilderapp ALTER COLUMN manifesturl SET NOT NULL;
The "true dependencies" usign db relationships were too strict for
reality - multiple entries can have the same textid, and that's what
we need to depend on. Resolving it for platform is handled in the
StackBuilder client.
This update requires the following SQL to be run in the database:
DROP TABLE downloads_stackbuilderapp_dependencies;
ALTER TABLE downloads_stackbuilderapp ADD COLUMN txtdependencies varchar(1000) NOT NULL DEFAULT '';
ALTER TABLE downloads_stackbuilderapp ALTER COLUMN txtdependencies DROP DEFAULT;
Closes#167
Previously this had to be rsynced outside of the website. By allowing the
upload here, and automatically purging the data from varnish, we will reach
"almost instant" updates of the ftp site structure on the web.
Still leaves the old templates around in case we want to go back on this,
as well as keeps the pure redirector service around so accesses from
things like stackbuilder don't stop working.
on the ftp server, instead of crawling the directoreis directly. This
removes the requirement to sync almost 10Gb worth of ftp site onto the
web server...
The pickle file for this is currently around 1Mb, so it's not a huge
burden on the server. If it grows larger in the future, we may want to
re-think this and split it up, or put it in a database format or something
like that.
part of the core, since it seems like it could be useful for other
kinds of objects as well in the future, but for now only the
software catalogue uses it.
