Reasons for upgrading

[Jeroen Demeyer]

Dear Sage upgraders,

I would like to do a small survey considering upgrading (the "sage
--upgrade" command) to understand better what the important features
are. If you don't ever upgrade nor plan to upgrade, please move along.

What are your major reasons for upgrading as opposed to building from
scratch? (multiple anwers possible, but only answer with things that are
important to you):

A) Upgrades build faster.
B) Upgrading is easier.
C) I have a bunch of optional packages installed that I want to preserve.
D) I have various patches to the repos (e.g. devel/sage) that I want to
preserve.
E) Upgrading is cool!
F) None of the above, I do upgrade but I don't really care.

[Martin Albrecht]

Definitely (A) for me (ATLAS insists on tuning on my box)

Cheers,
Martin

--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://martinralbrecht.wordpress.com/
_jab: martinr...@jabber.ccc.de

[Simon King]

Hi Jeroen,

On 2013-04-30, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> What are your major reasons for upgrading as opposed to building from
> scratch? (multiple anwers possible, but only answer with things that are
> important to you):
>
> A) Upgrades build faster.
> B) Upgrading is easier.
> C) I have a bunch of optional packages installed that I want to preserve.
> D) I have various patches to the repos (e.g. devel/sage) that I want to
> preserve.
> E) Upgrading is cool!
> F) None of the above, I do upgrade but I don't really care.

When I was young, I used upgrade because I thought this was the natural
way to get the latest Sage release.

Currently, I do not upgrade. However, I *would* consider to upgrade,
provided that A), C) and D) holds, and provided that one can easily
upgrade to the latest beta version.

Does D) really work, currently? If it did, it would be my main reason
for using upgrade, because I find it a pain in the neck to first build
Sage from scratch, then check for each patch in my patch queue whether
it has meanwhile been merged, and import the remaining patches from my
previous Sage installation.

So, if upgrading would automatically clean the patch queue, by detecting
which patches have been merged, it would really be E)!

Best regards,
Simon

[Travis Scrimshaw]

Hey,

On 2013-04-30, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> What are your major reasons for upgrading as opposed to building from
> scratch? (multiple anwers possible, but only answer with things that are
> important to you):
>
> A) Upgrades build faster.
> B) Upgrading is easier.
> C) I have a bunch of optional packages installed that I want to preserve.
> D) I have various patches to the repos (e.g. devel/sage) that I want to
> preserve.
> E) Upgrading is cool!
> F) None of the above, I do upgrade but I don't really care.

I never upgraded, I was very sternly warned against it.

 

Currently, I do not upgrade. However, I *would* consider to upgrade,
provided that A), C) and D) holds, and provided that one can easily
upgrade to the latest beta version. 

Does D) really work, currently? If it did, it would be my main reason
for using upgrade, because I find it a pain in the neck to first build
Sage from scratch, then check for each patch in my patch queue whether
it has meanwhile been merged, and import the remaining patches from my
previous Sage installation.

So, if upgrading would automatically clean the patch queue, by detecting
which patches have been merged, it would really be E)!

   However, I would like to see upgrades if A) through C) held with something similar to what Simon suggested was true, then D), and E). I would also like to formalize what Simon said as another possible answer:

G) Upgrading to the latest development release

Although I guess when we switch over to git, developers using the repo shouldn't have a difficult time with upgrading...

Actually, one last thing I just thought of, we can't completely control the rebuild time of sage since there are certain files which trigger a major recompilation. Although I've been told that one of the longest part of a source build comes from the ATLAS part, and I guess we'd always be cutting that out... (please correct me if I'm wrong)

Best,

Travis

[kcrisman]

A) Upgrades build faster.
B) Upgrading is easier.

Yes to these. 

[mmarco]

After having some trouble with upgrading a couple of times, which
broke my sage installation, i got used to rebuild from scratch each
version.

[Nils Bruin]

On Apr 30, 3:52 am, Martin Albrecht <martinralbre...@googlemail.com>
wrote:

> Definitely (A) for me (ATLAS insists on tuning on my box)

I had that problem too. I then lifted the required files out of atlas
and put them in a directory and now I just point SAGE_ATLAS_LIB at it.
Then full installation isn't so bad.

If I were to get into a situation that sage wants to build GCC as
well, I'd hope a similar solution can be found. Are OSX people happy
to just build GCC from scratch every time?

[Jeroen Demeyer]

On 04/30/2013 05:41 PM, Nils Bruin wrote:
> If I were to get into a situation that sage wants to build GCC as
> well, I'd hope a similar solution can be found. Are OSX people happy
> to just build GCC from scratch every time?

It's not required to (re)build GCC. If your system has a sufficiently
recent gcc, g++ and gfortran, then GCC isn't built.

[P Purkayastha]

A) for me.

However, since around 5.6 I had trouble with atlas-3.8.4 on my laptop
and so I had to manually ensure that atlas-3.10 was installed from trac.
Then upgrading became impossible because of the patches to sage and sage
root.

Also upgrading from beta -> rc -> release wasn't really supported. I
upgraded twice using the git repo 5.9.beta4 -> beta5 -> rc0. And the
upgrades were smooth.

[leif]

Yes, but AFAIK there are no scripts to save a Sage-built local GCC
installation somewhere else for reuse (at least by another Sage
installation), nor is there any documentation on how to do that.

The same is true for ATLAS btw., although doing it manually is certainly
easier (or more straight-forward) in the case of ATLAS.


-leif

P.S.: I'm of course ok with continually punishing Apple users (and
others) for not having recent GCC versions.

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[leif]

Jeroen Demeyer wrote:
> A) Upgrades build faster.
> B) Upgrading is easier.
> C) I have a bunch of optional packages installed that I want to preserve.
> D) I have various patches to the repos (e.g. devel/sage) that I want to
> preserve.
> E) Upgrading is cool!
> F) None of the above, I do upgrade but I don't really care.

A, B, E. F and

G) It saves download volume/time.
H) It saves disk space.
I) No risk, no fun. ("WARNING: This is a source-based upgrade, which
could take hours, fail, and render your Sage install useless!!")


I actually stopped testing/trying to upgrade when upgrading *from* devel
versions broke (which was a newly introduced "feature" rather than a
bug), as the resulting installations quickly became pretty useless.


-leif

[leif]

P.S.: We should probably ask that on sage-support, ... as well.

[john_perry_usm]

I know you said to move along if I don't upgrade, but I would like to upgrade if it weren't discommended or unreliable, for reasons (A) and (C). I actually thought it was discommended. I really need to pay more attention...

john perry

[David Roe]

On Tue, Apr 30, 2013 at 11:29 AM, leif <not.r...@online.de> wrote:

Jeroen Demeyer wrote:

On 04/30/2013 05:41 PM, Nils Bruin wrote:

If I were to get into a situation that sage wants to build GCC as
well, I'd hope a similar solution can be found. Are OSX people happy
to just build GCC from scratch every time?

It's not required to (re)build GCC. If your system has a sufficiently
recent gcc, g++ and gfortran, then GCC isn't built.

Yes, but AFAIK there are no scripts to save a Sage-built local GCC installation somewhere else for reuse (at least by another Sage installation), nor is there any documentation on how to do that.

That would be nice....

David

[Benjamin Jones]

A, and B. D is nice but not essential.

--
Benjamin Jones
benjami...@gmail.com

--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Robert Bradshaw]

On Tue, Apr 30, 2013 at 10:49 AM, leif <not.r...@online.de> wrote:
> Jeroen Demeyer wrote:
>>
>> A) Upgrades build faster.
>> B) Upgrading is easier.
>> C) I have a bunch of optional packages installed that I want to preserve.
>> D) I have various patches to the repos (e.g. devel/sage) that I want to
>> preserve.
>> E) Upgrading is cool!
>> F) None of the above, I do upgrade but I don't really care.
>
>
> A, B, E. F and
>
> G) It saves download volume/time.
> H) It saves disk space.
> I) No risk, no fun. ("WARNING: This is a source-based upgrade, which could
> take hours, fail, and render your Sage install useless!!")

A (especially building gcc these days), B, D, and H. It's also a pain
to have several sage-X versions floating around and trying to remember
in which ones you were developing which features (and then rebasing
them to the most recent one is a pain too).

- Robert

[Keshav Kini]

Simon King <simon...@uni-jena.de> writes:
> Does D) really work, currently? If it did, it would be my main reason
> for using upgrade, because I find it a pain in the neck to first build
> Sage from scratch, then check for each patch in my patch queue whether
> it has meanwhile been merged, and import the remaining patches from my
> previous Sage installation.

This can be made a bit easier. See
http://www.sagemath.org/doc/developer/walk_through.html#upgrading-sage-with-queues-present
(my first contribution to Sage, way back when, IIRC :) )

-Keshav

[Jeroen Demeyer]

On 04/30/2013 07:49 PM, leif wrote:
> H) It saves disk space.

How do upgrades save disk space???

[Simon King]

On 2013-04-30, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:

The alternative is (at least temporarily) to have several sage
installations at the same time.

[Julien Puydt]

Another alternative : just have a bdist of the last working install.

That's what I do on my ARM box where room is sparse (or scarce?).

Snark on #sagemath

Simon King <simon...@uni-jena.de> a écrit :

--
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.