Archive old-style spkg files

[Volker Braun]

Since it is a recurring point of confusion I'll move all the old-style spkgs so they will not be found automatically. You can still manually install them if you specify the precise location of the archive folder. Really, nobody wants to install ancient Sage packages.

Harald: The current achive section on the web page refers to http://old.files.sagemath.org/spkg/archive/, so I guess I should make a new /data/files/spkg/archive directory on the file server?

[Harald Schilly]

On Tue, Aug 4, 2015 at 2:48 PM, Volker Braun <vbrau...@gmail.com> wrote:
> Harald: The current achive section on the web page refers to
> http://old.files.sagemath.org/spkg/archive/, so I guess I should make a new
> /data/files/spkg/archive directory on the file server?

Uhm, I'm not sure what you mean. After dereferencing symlinks, this
old.files... URL ends up in
/data/files-old/spkg/archive/
Hence I think the directory you want to create already exists?

The only difference is, that the content of /data/files-old is not
mirrored out, only /data/files.

-- harald

[Thierry]

Hi,

since some people still rely on old versions of Sage and may still have to
download old-style spkgs, it seems to me a better solution than removing
the archives (or moving their URL so that they will not be found by older
Sage installs) is to do the following:

- let them online for old installs of Sage, with untouchd URLs.
- stop relying on them on the new versions of Sage (just remove stuff that
look for such packages in src/bin/*, but still let the possibility to
install a .spkg from a complete URL of a local file, because of third
party .spkgs). It will have the huge benefit to simplify checking for the
existence of packages and all the package management.

Of course, one may complain that some interesting packages are only
available as old-style spkg and will be missing. Fair enough, but we have
to know which ones require repackaging work. Note that there is a lot of
old unused or broken stuff, so an important step is to know precisely
which olsd-style packages have to be repackaged or we will do some useless
work. Note that the interesting spkg that can be pip-installed do not need
to be repackaged either. I personally do not care if everything get
trashed since all old-style packages that i was interested in are now
repackaged (or on the way to get reviewed, let me take the opportunity to
hint for #10224).

So, what i propose it to separate the useful to the bitrotting, so that we
all know what still needs to be repackaged because it seems clear that the
few remaining interesting old-style spkg are used by people who do not
know how to repackage them. I opened a list on the wiki page and invite
anyone that rely on some important old-style spkg to edit it:

http://wiki.sagemath.org/Classify%20old-style%20packages

I started to classify the packages and there are still some for which it
is not clear to me what to do, it may not be up-to-date since i started it
during sage 6.7, but i guess it is a good starting point.

Ciao,
Thierry

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

[Volker Braun]

I've removed the search-old-spkg bug/misfeature at http://trac.sagemath.org/ticket/19004 (needs review)

Also adds useful diagnostics if the package name cannot be found:

$ sage -i python

Attempting to download package python

Error: could not find a package matching python

       Try 'sage --package list' to see the available packages

       Did you mean: cython, ipython, python2, python3, patch?