On Tue, May 12, 2015 at 07:19:07AM -0700, Volker Braun wrote:
> * The package type (standard/optional/experimental) should be in a file
> inside the package directory
+1. Actually, i have a prototype of this for the purpose of checking to
the upstream website if a newerver version is out (i did it mainly for
openssl, but it now covers most packages), and get some other information
by browsing the source code (e.g. which are installed, how many patches,
> * The build system should check that it builds only standard packages
Or even conversely, generate build/deps from such atomic informations, of
course, we should mention both
- the priority (toolchain, base, standard, optional, experimental)
- the dependencies
This would have the benefits over the current system to be able to provide
dependencies not only for standard packages but also for optional ones, we
could also mention pip dependencies there.
If people think it is interesting and has a chance to be merged at some
point, i can update my prototype to that aim. I was shy to propose it
since it is written in Python, and, if it is used to compile the whole
stuff, then Python will be a requirement, which seems currently pretty
> * Old-style spkgs shouldn't be mashed together with new-style packages,
> that is super confusing if you have both.
> * Instead, put all old spkgs in a separate category (sage -old-spkg or so),
> or list them separately at the end of "sage -optional"
+1, see my previous answer, or why not simply just trash old-style, while
migrating interesting ones to new-style ? They should not be much in the
list since those were not updated since a while now, and there was no
complain, so i guess most are unused or do not deal with mathematics (e.g.
trac, nose, beautifulsoup,...).
> On Tuesday, May 12, 2015 at 3:57:47 PM UTC+2, Nathann Cohen wrote:
> > > That's perhaps a bit problematic at the moment; also, at least some
> > > tests may require internet access (although we could tag them
> > > accordingly). Should we document/test their versions as well?
> > Technically, the list of standard packages is available in Sage
> > directly (build/install). Maybe we should have a file whose content is
> > the list of standard packages (and only that) which build/install
> > could then load?
> > Volker, what do you think?
> > It seems that all lines in build/install are of the form
> > package_name=`newest_version package_name`. Couldn't we generate this
> > from the list of packages instead?
> > > Furthermore, in the "git layout" we only have "new-style" packages
> > > (which are currently still a subset of standard+optional), with no
> > > differentiation between standard and optional; there, experimental
> > > packages (and "the" huge one?) are missing completely AFAIK.
> > Yep, only those which have been converted into 'new-style' packages
> > appear there. Though you can get these lists with:
> > sage -standard
> > sage -optional
> > sage -experimental
> > All of them require an internet connection.
> > Nathann