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

[Sven-Hendrik Haase]

 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