[aur-general] Proposal to move sage-mathematics into [community].

newer
[aur-general] Moving the following...

Thomas Dziedzic

12 Aug 2010 12 Aug '10

5:07 p.m.

Hello, I am the maintainer of aur/sage-mathematics. I think this package has matured to the point where it could be included into the community repository. There are no issues with this package that I am currently aware of. Its inclusion into community would probably save a lot of compilation time for everyone. The namcap and built package could be found at: http://pkgbuild.com/~td123/ The package is ~700MB per architecture. I didn't modularize this package because upstream doesn't intend to modularize it, and because of the amount of work that would require, not only to split everything off, but to make sure nothing breaks at the same time. Case in point, http://github.com/cschwan/sage-on-gentoo I would like to start discussing its inclusion now. Cheers!

Show replies by date

Ronald van Haren

12 Aug 12 Aug

5:34 p.m.

New subject: [aur-general] Proposal to move sage-mathematics into [community].

On Thu, Aug 12, 2010 at 7:07 PM, Thomas Dziedzic wrote:

...

Hello, I am the maintainer of aur/sage-mathematics. I think this package has matured to the point where it could be included into the community repository. There are no issues with this package that I am currently aware of.

Its inclusion into community would probably save a lot of compilation time for everyone.

The namcap and built package could be found at: http://pkgbuild.com/~td123/ The package is ~700MB per architecture.

I didn't modularize this package because upstream doesn't intend to modularize it, and because of the amount of work that would require, not only to split everything off, but to make sure nothing breaks at the same time. Case in point, http://github.com/cschwan/sage-on-gentoo

I would like to start discussing its inclusion now.

Cheers!

Sorry it doesn't really make sense to me. Why would we want to duplicate all these packages that we already have in the repos with one big fat binary containing them all? I mean, all SAGE is doing is getting sources from open source projects and merge them in one big fat distribution if I'm not mistaken? Ronald

Thomas Dziedzic

5:54 p.m.

New subject: [aur-general] Proposal to move sage-mathematics into [community].

On Thu, Aug 12, 2010 at 12:34 PM, Ronald van Haren wrote:

...

On Thu, Aug 12, 2010 at 7:07 PM, Thomas Dziedzic wrote:

...
Hello, I am the maintainer of aur/sage-mathematics. I think this package has matured to the point where it could be included into the community repository. There are no issues with this package that I am currently aware of.

Its inclusion into community would probably save a lot of compilation time for everyone.

The namcap and built package could be found at: http://pkgbuild.com/~td123/ http://pkgbuild.com/%7Etd123/ The package is ~700MB per architecture.

I didn't modularize this package because upstream doesn't intend to modularize it, and because of the amount of work that would require, not only to split everything off, but to make sure nothing breaks at the same time. Case in point, http://github.com/cschwan/sage-on-gentoo

I would like to start discussing its inclusion now.

Cheers!

Sorry it doesn't really make sense to me. Why would we want to duplicate all these packages that we already have in the repos with one big fat binary containing them all? I mean, all SAGE is doing is getting sources from open source projects and merge them in one big fat distribution if I'm not mistaken?

Ronald

It provides a common interface (namely python) for many applications that it packages itself. It also includes its own patches to those packages, like implementing features not in upstream. Finally, everything it compiles itself, python, gcc-fortran, etc. is completely isolated from the system.

Thomas Bächler

11:03 p.m.

New subject: [aur-general] Proposal to move sage-mathematics into [community].

Am 12.08.2010 19:34, schrieb Ronald van Haren:

...

Sorry it doesn't really make sense to me. Why would we want to duplicate all these packages that we already have in the repos with one big fat binary containing them all? I mean, all SAGE is doing is getting sources from open source projects and merge them in one big fat distribution if I'm not mistaken?

You'll have a hard time making sage work trying to use our distro packages. We can and should remove some of the libraries from the build process, especially readline. Taking everything apart and putting our distro stuff will probably not only break sage, but be a ton of work.

Xyne

14 Aug 14 Aug

1:46 a.m.

...

I didn't modularize this package because upstream doesn't intend to modularize it, and because of the amount of work that would require, not only to split everything off, but to make sure nothing breaks at the same time. Case in point, http://github.com/cschwan/sage-on-gentoo

I would like to start discussing its inclusion now.

Considering Sage's popularity, both on the AUR (160 votes for the source version, 130 votes for the binary version) and in general, along with how long it takes to compile, I definitely think this should be included in [community]. I fully agree with the sentiments regarding duplication of packages, but that is an upstream issue and unavoidable without a very heavy-hands-on approach to the package, as already mentioned. The package itself though is more than just a mesh of its components and thus provides a real utility despite the underlying duplication. In the absence of an upstream willingness to modularize the components, the next best approach would be to have the package "provide" as many of its components as possible (if any) to enable users to avoid redundant packages on their own system. This would offset the cost of the duplication and reduce user-mirror bandwidth and user diskspace. The cost of the extra bits on the mirrors themselves is unfortunate but far from critical. I would also support tweaking the PKGBUILD or applying relatively simple patches if it would expose more of the components to the system in such a way that they could be counted as "provides" So +1 for its inclusion from me. Regards, Xyne

Sven-Hendrik Haase

2:31 a.m.

New subject: [aur-general] Proposal to move sage-mathematics into [community].

On 14.08.2010 03:46, Xyne wrote:

...

...
I didn't modularize this package because upstream doesn't intend to modularize it, and because of the amount of work that would require, not only to split everything off, but to make sure nothing breaks at the same time. Case in point, http://github.com/cschwan/sage-on-gentoo

I would like to start discussing its inclusion now. Considering Sage's popularity, both on the AUR (160 votes for the source version, 130 votes for the binary version) and in general, along with how long it takes to compile, I definitely think this should be included in [community].

I fully agree with the sentiments regarding duplication of packages, but that is an upstream issue and unavoidable without a very heavy-hands-on approach to the package, as already mentioned. The package itself though is more than just a mesh of its components and thus provides a real utility despite the underlying duplication.

In the absence of an upstream willingness to modularize the components, the next best approach would be to have the package "provide" as many of its components as possible (if any) to enable users to avoid redundant packages on their own system. This would offset the cost of the duplication and reduce user-mirror bandwidth and user diskspace. The cost of the extra bits on the mirrors themselves is unfortunate but far from critical.

I would also support tweaking the PKGBUILD or applying relatively simple patches if it would expose more of the components to the system in such a way that they could be counted as "provides"

So +1 for its inclusion from me.

Regards, Xyne

If I have understood your correctly, you want sage to provide python and all its other components as if they were vanilla? I have no experience at all with sage but your idea sounds like it would invite a lot of very hard to debug breakage. From my understanding, the duplicated packages that sage would provide are heavily modified. How can you expect them to behave like their vanilla versions without extensive testing? If a problem is unlikely to occur then go for it. However, the thought of making sage provide python alone would be rather scary (and unflexible). I'd just bite the bullet and include sage in all its glory and self-containment and leave the system packages in piece. -- Sven-Hendrik

Loui Chang

3:14 a.m.

New subject: [aur-general] Proposal to move sage-mathematics into [community].

On Sat 14 Aug 2010 04:31 +0200, Sven-Hendrik Haase wrote:

...

On 14.08.2010 03:46, Xyne wrote:

...
...
I didn't modularize this package because upstream doesn't intend to modularize it, and because of the amount of work that would require, not only to split everything off, but to make sure nothing breaks at the same time. Case in point, http://github.com/cschwan/sage-on-gentoo

I would like to start discussing its inclusion now.

I fully agree with the sentiments regarding duplication of packages, but that is an upstream issue and unavoidable without a very heavy-hands-on approach to the package, as already mentioned. The package itself though is more than just a mesh of its components and thus provides a real utility despite the underlying duplication.

In the absence of an upstream willingness to modularize the components, the next best approach would be to have the package "provide" as many of its components as possible (if any) to enable users to avoid redundant packages on their own system. This would offset the cost of the duplication and reduce user-mirror bandwidth and user diskspace. The cost of the extra bits on the mirrors themselves is unfortunate but far from critical.

If I have understood your correctly, you want sage to provide python and all its other components as if they were vanilla?

I have no experience at all with sage but your idea sounds like it would invite a lot of very hard to debug breakage. From my understanding, the duplicated packages that sage would provide are heavily modified. How can you expect them to behave like their vanilla versions without extensive testing?

It seems pretty ridiculous that they wouldn't have made provisions to use a system python rather than a bundled one. I maintain brlcad which bundles tcl/tk, boost, and a host of other libs but they have a proper build system which can check for and use system libs. Some of the libs are more obscure and probably should be bundled. I can imagine the same situation would occur with sage-mathematics. I'm left wondering why sage can't get their modifications incorporated upstream. I don't imagine using sage any time soon, but I can imagine users being a little peeved if they required virtually two installations of python - or any other major package.

Stefan Husmann

3:31 a.m.

New subject: [aur-general] Proposal to move sage-mathematics into [community].

Am 14.08.2010 05:14, schrieb Loui Chang:

...

On Sat 14 Aug 2010 04:31 +0200, Sven-Hendrik Haase wrote:

...
On 14.08.2010 03:46, Xyne wrote:

...
...
I didn't modularize this package because upstream doesn't intend to modularize it, and because of the amount of work that would require, not only to split everything off, but to make sure nothing breaks at the same time. Case in point, http://github.com/cschwan/sage-on-gentoo

I would like to start discussing its inclusion now.

I fully agree with the sentiments regarding duplication of packages, but that is an upstream issue and unavoidable without a very heavy-hands-on approach to the package, as already mentioned. The package itself though is more than just a mesh of its components and thus provides a real utility despite the underlying duplication.

In the absence of an upstream willingness to modularize the components, the next best approach would be to have the package "provide" as many of its components as possible (if any) to enable users to avoid redundant packages on their own system. This would offset the cost of the duplication and reduce user-mirror bandwidth and user diskspace. The cost of the extra bits on the mirrors themselves is unfortunate but far from critical.

If I have understood your correctly, you want sage to provide python and all its other components as if they were vanilla?

I have no experience at all with sage but your idea sounds like it would invite a lot of very hard to debug breakage. From my understanding, the duplicated packages that sage would provide are heavily modified. How can you expect them to behave like their vanilla versions without extensive testing?

It seems pretty ridiculous that they wouldn't have made provisions to use a system python rather than a bundled one. I maintain brlcad which bundles tcl/tk, boost, and a host of other libs but they have a proper build system which can check for and use system libs. Some of the libs are more obscure and probably should be bundled. I can imagine the same situation would occur with sage-mathematics. I'm left wondering why sage can't get their modifications incorporated upstream.

I don't imagine using sage any time soon, but I can imagine users being a little peeved if they required virtually two installations of python - or any other major package.

The users of sage will not be peeved about that, because it is very well known that this is the case. Or if they are, will not use sage. Regards Stefan

Peter Lewis

8:17 a.m.

New subject: [aur-general] Proposal to move sage-mathematics into [community].

On Saturday 14 August 2010 at 04:31 Stefan Husmann wrote:

...

Am 14.08.2010 05:14, schrieb Loui Chang:

...
On Sat 14 Aug 2010 04:31 +0200, Sven-Hendrik Haase wrote:

...
On 14.08.2010 03:46, Xyne wrote:

...
I fully agree with the sentiments regarding duplication of packages, but that is an upstream issue and unavoidable without a very heavy-hands-on approach to the package, as already mentioned. The package itself though is more than just a mesh of its components and thus provides a real utility despite the underlying duplication.

In the absence of an upstream willingness to modularize the components, the next best approach would be to have the package "provide" as many of its components as possible (if any) to enable users to avoid redundant packages on their own system. This would offset the cost of the duplication and reduce user-mirror bandwidth and user diskspace. The cost of the extra bits on the mirrors themselves is unfortunate but far from critical.

If I have understood your correctly, you want sage to provide python and all its other components as if they were vanilla?

As someone who's used sage off and on over the last year or so, I originally thought that Xyne's approach would be best, but yeah it is such a big pile of stuff duplicating so many things that I don't think that's practical. It may be that there are a few core components (however we define that) like maxima or octave that can be "provided", but if it "provides" everything then upon uninstalling it, I'd have to remember to reinstall the vanilla python et al. That doesn't sound too feasible to me.

...

...
It seems pretty ridiculous that they wouldn't have made provisions to use a system python rather than a bundled one. I maintain brlcad which bundles tcl/tk, boost, and a host of other libs but they have a proper build system which can check for and use system libs. Some of the libs are more obscure and probably should be bundled. I can imagine the same situation would occur with sage-mathematics. I'm left wondering why sage can't get their modifications incorporated upstream.

I don't imagine using sage any time soon, but I can imagine users being a little peeved if they required virtually two installations of python - or any other major package.

The users of sage will not be peeved about that, because it is very well known that this is the case. Or if they are, will not use sage.

Well, many *potential* users will be, including me. In the end this frustration led me to uninstall it. I just don't have enough disk space for duplicated versions of virtually everything! :-( Sage is a good step in the right direction, but they really need to think about better integration. It's not a software package, but a distro really. I wonder if the sage team receives feedback from packagers about what a pain in the arse it is? Pete.

Xyne

11:19 a.m.

Sven-Hendrik Haase wrote:

...

If I have understood your correctly, you want sage to provide python and all its other components as if they were vanilla?

No... Peter Lewis wrote:

...

It may be that there are a few core components (however we define that) like maxima or octave that can be "provided"...

This is mostly what I had in mind. Even with modifications, some of the component packages such as maxima or octave should fulfill most dependencies of packages that require them and could thus be used instead of the vanilla packages by users who require Sage. Even if it only provides a few, it would still help offset the cost of installing the package. I wrote 'to have the package "provide" as many of its components as possible (if any)' *because* I doubt that most of them can be exposed. Loui Chang wrote:

...

It seems pretty ridiculous that they wouldn't have made provisions to use a system python rather than a bundled one. I maintain brlcad which bundles tcl/tk, boost, and a host of other libs but they have a proper build system which can check for and use system libs. Some of the libs are more obscure and probably should be bundled. I can imagine the same situation would occur with sage-mathematics. I'm left wondering why sage can't get their modifications incorporated upstream.

I don't imagine using sage any time soon, but I can imagine users being a little peeved if they required virtually two installations of python - or any other major package.

It *is* ridiculous. The upstream developers either think that "disk is cheap" and don't care, or they think that Sage is the be-all-end-all mathematics package and that no one would ever need any of the vanilla components. That's just the way it is though and users of Sage know this. Aside from incessantly nagging upstream, there is nothing that can be done about it, which is why we're left with working around the duplication. Regards, Xyne

Thomas Dziedzic

16 Aug 16 Aug

4:43 p.m.

New subject: [aur-general] Proposal to move sage-mathematics into [community].

On Sat, Aug 14, 2010 at 6:19 AM, Xyne wrote:

...

Sven-Hendrik Haase wrote:

...
If I have understood your correctly, you want sage to provide python and all its other components as if they were vanilla?

No...

Peter Lewis wrote:

...
It may be that there are a few core components (however we define that) like maxima or octave that can be "provided"...

This is mostly what I had in mind. Even with modifications, some of the component packages such as maxima or octave should fulfill most dependencies of packages that require them and could thus be used instead of the vanilla packages by users who require Sage. Even if it only provides a few, it would still help offset the cost of installing the package.

I wrote 'to have the package "provide" as many of its components as possible (if any)' *because* I doubt that most of them can be exposed.

Loui Chang wrote:

...
It seems pretty ridiculous that they wouldn't have made provisions to use a system python rather than a bundled one. I maintain brlcad which bundles tcl/tk, boost, and a host of other libs but they have a proper build system which can check for and use system libs. Some of the libs are more obscure and probably should be bundled. I can imagine the same situation would occur with sage-mathematics. I'm left wondering why sage can't get their modifications incorporated upstream.

I don't imagine using sage any time soon, but I can imagine users being a little peeved if they required virtually two installations of python - or any other major package.

It *is* ridiculous. The upstream developers either think that "disk is cheap" and don't care, or they think that Sage is the be-all-end-all mathematics package and that no one would ever need any of the vanilla components.

That's just the way it is though and users of Sage know this. Aside from incessantly nagging upstream, there is nothing that can be done about it, which is why we're left with working around the duplication.

Regards, Xyne

If anyone has any other comments or pressing issues, please respond now. I will wait another day before moving it into community.

Ronald van Haren

5:24 p.m.

New subject: [aur-general] Proposal to move sage-mathematics into [community].

On Mon, Aug 16, 2010 at 6:43 PM, Thomas Dziedzic wrote:

...

On Sat, Aug 14, 2010 at 6:19 AM, Xyne wrote:

...
Sven-Hendrik Haase wrote:

...
If I have understood your correctly, you want sage to provide python and all its other components as if they were vanilla?

No...

Peter Lewis wrote:

...
It may be that there are a few core components (however we define that) like maxima or octave that can be "provided"...

This is mostly what I had in mind. Even with modifications, some of the component packages such as maxima or octave should fulfill most dependencies of packages that require them and could thus be used instead of the vanilla packages by users who require Sage. Even if it only provides a few, it would still help offset the cost of installing the package.

I wrote 'to have the package "provide" as many of its components as possible (if any)' *because* I doubt that most of them can be exposed.

Loui Chang wrote:

...
It seems pretty ridiculous that they wouldn't have made provisions to use a system python rather than a bundled one. I maintain brlcad which bundles tcl/tk, boost, and a host of other libs but they have a proper build system which can check for and use system libs. Some of the libs are more obscure and probably should be bundled. I can imagine the same situation would occur with sage-mathematics. I'm left wondering why sage can't get their modifications incorporated upstream.

I don't imagine using sage any time soon, but I can imagine users being a little peeved if they required virtually two installations of python - or any other major package.

It *is* ridiculous. The upstream developers either think that "disk is cheap" and don't care, or they think that Sage is the be-all-end-all mathematics package and that no one would ever need any of the vanilla components.

That's just the way it is though and users of Sage know this. Aside from incessantly nagging upstream, there is nothing that can be done about it, which is why we're left with working around the duplication.

Regards, Xyne

If anyone has any other comments or pressing issues, please respond now. I will wait another day before moving it into community.

nah, just in case you are going to use provides, make sure that existing frontends work with it and such. Ronald

Thomas Dziedzic

5:54 p.m.

New subject: [aur-general] Proposal to move sage-mathematics into [community].

On Mon, Aug 16, 2010 at 12:24 PM, Ronald van Haren wrote:

...

...
On Sat, Aug 14, 2010 at 6:19 AM, Xyne wrote:

...
Sven-Hendrik Haase wrote:

...
If I have understood your correctly, you want sage to provide python and all its other components as if they were vanilla?

No...

Peter Lewis wrote:

...
It may be that there are a few core components (however we define

...
...
like

...
maxima or octave that can be "provided"...

This is mostly what I had in mind. Even with modifications, some of the component packages such as maxima or octave should fulfill most dependencies of packages that require them and could thus be used instead of the vanilla packages by users who require Sage. Even if it only provides a few, it would still help offset the cost of installing the package.

I wrote 'to have the package "provide" as many of its components as possible (if any)' *because* I doubt that most of them can be exposed.

Loui Chang wrote:

...
It seems pretty ridiculous that they wouldn't have made provisions to use a system python rather than a bundled one. I maintain brlcad which bundles tcl/tk, boost, and a host of other libs but they have a proper build system which can check for and use system libs. Some of the libs are more obscure and probably should be bundled. I can imagine the same situation would occur with sage-mathematics. I'm left wondering why sage can't get their modifications incorporated upstream.

I don't imagine using sage any time soon, but I can imagine users being a little peeved if they required virtually two installations of python

On Mon, Aug 16, 2010 at 6:43 PM, Thomas Dziedzic wrote: that) -

...
...
...
or any other major package.

It *is* ridiculous. The upstream developers either think that "disk is cheap" and don't care, or they think that Sage is the be-all-end-all mathematics package and that no one would ever need any of the vanilla components.

That's just the way it is though and users of Sage know this. Aside from incessantly nagging upstream, there is nothing that can be done about it, which is why we're left with working around the duplication.

Regards, Xyne

If anyone has any other comments or pressing issues, please respond now. I will wait another day before moving it into community.

nah, just in case you are going to use provides, make sure that existing frontends work with it and such.

Ronald

I'm not going to use provides because they are sage's internal versions. Some are outdated or patched and using them independently is not upstream's intentions.

5023

Age (days ago)

5027

Last active (days ago)

List overview

Download

12 comments

8 participants

participants (8)

Loui Chang
Peter Lewis
Ronald van Haren
Stefan Husmann
Sven-Hendrik Haase
Thomas Bächler
Thomas Dziedzic
Xyne