On 06/ 9/10 12:40 PM, Dima Pasechnik wrote:
Well, I saw upgrades fail repeatedly, and William was writing here
that -upgrade is basically not ready
for prime time use.
Indeed, one needs to have at least an spkg dependencies mechanism in
place, before -upgrade
can be done in a fool-proof way. At the moment it is adhoc - an spkg
can be checking that another spkg is there and has version at least
something, but this is not supported in any consistent way, e.g. like
it is done with Debian packages.
I.e. there is no declarative facilities in place that would allow one
to specify such an interdependency,
they rather need to be hard-coded into the spkg install script.
So one needs to develop/adopt such a scheme, before -upgrade can be
made safe...
I've looked briefly at /local/bin/sage-update. Something that I think is flawed
is that if package B depends on A, and A is updated, B is not recompiled.
The 'deps' file only lists the dependencies, but not version numbers.
Looking at spkg/standard/deps, I see:
$(INST)/$(FPLLL): $(BASE) $(INST)/$(MPIR) $(INST)/$(MPFR)
$(SAGE_SPKG) $(FPLLL) 2 >&1
Let's assume MPIR gets updated. It would be wise to recompile fplll, even if its
not necessary to do so. Knowing when it is necessary and when it is not
necessary, would be hard to know.
As far as I can see, there is nothing to do that. Consulting
'spkg/standard/deps' could be used to determine if those packages need updating.
The other issue is that spkg/sandard/deps sometimes has inferred dependencies.
For example, Pyton depends on zlib. PolyBoRi depends on Pyton. But zlib is not
listed as a dependancy of PolyBori, though it is inferred via python.
IMHO, if zlib is rebuilt, python should, and so polybori rebuilt. At the moment,
neither will happen if I've understood things correctly.
And I imagine replies here saying that it would increase the
complexity of Sage, without adding any new useful functionality.
I can only say that in the long term it would save developers time, to
have such a scheme in place...
Dima
I agree with you that it would save developer time. Less time spent building can
mean more time spent improving documentation, testing, coding etc.
I don't know if there is a simple way to do this. Rather than check for a
package being at least of version X, we can probably just check if the package
is of a different version to already installed.
It would be useful if a failed upgrade could be worked on, to try to get it to
work, rather then just say "It's failed, so I'll rebuild from scratch".
Dave
On Jun 9, 11:10 am, David Kirkby<david.kir...@onetel.net> wrote:
On 6 June 2010 11:47, François Bissey<f.r.bis...@massey.ac.nz> wrote:
On 06/ 6/10 10:53 AM, François Bissey wrote:
You could also try
sage -ba
which will rebuild from scratch all Cython code.
OK I will give it a go.
No improvement. I am considering this upgrade officially failed
on my machine.
Francois
Can anyone tell me what happens in a 'sage -upgrade'? I'm puzzled why this
can't be made to work. I would have thought as a minimum one would need to
1) Rebuild any new standard packages.
2) Rebuild any standard package which depends on another package which has
been upgraded.
3) Rebuild the library.
Is '(2)' being done? If not, I suspect it would be more reliable.
I would think it is done that way. Although sometimes there are difficulties.
It's possible that I didn't actually found the right culprit in this case.
pynac only depends on python so there's not much to rebuild.
The list of updated package is very short so this is puzzling but bugs
in upgrading system happen. Possibly in this case something went subtly
wrong from 4.4.1->4.4.2->4.4.3
It just that
a) Permitting upgrades, rather than a total reinstall, was a good idea
of William's. (At least I think it was his idea. If not, I apologise
to whoevers idea it was).
b) It sometimes fails, which makes it far less useful.
c) When it does fail, you end up with a screwed up installation of Sage.
d) Other projects seem able to manage upgrades. I've never had an
upgrade of Firefox or Thunderbird fail, despite I allow automatic
updates.
I've had updates of OpenSolaris fail, but in that case it does at
least clone the boot environment first, so if the upgrade fails, one
just picks the previous entry on the grub menu, and one goes back to
the previous version of the operating system. The system is
unavailable for only the time it takes to reboot. twice - first to the
failed installation, then back to the previous installation. One can
continue to use the operating system during the upgrade, just as one
can with Windows live updates.
Dave
Dave
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
