> On Thursday, May 12, 2011 3:18:29 PM UTC-7, Ondrej Certik wrote:
> > On Thu, May 12, 2011 at 5:29 AM, Maarten Derickx
> > <m.derick...@gmail.com> wrote:
> > [...]
> >
> > >> What would be the advantage of having it in the SPKG itself?
> > >
> > > That it wil be compatible with parallel building as mentioned earlier.
> > >
> > >> Like if you want to install two packages that overwrite the same file?
> > >
> > > I don't think we should never do (or even want) such a thing. I think
> > > every spkg should only touch it's own files (or else we will get into
> > > an unpredictable mess if we also want uninstall and parallel
> > > building), if you really want an spkg to touch a file created by for
> > > example foo.spkg, one should instead make a patch for the foo.spkg.
> > > Maybe we should add some code that checks if there are spkg's breaking
> > > this rule.
> >
> > Definitely, two packages should not override the same files.
>
> Does ATLAS sometimes (depending on the OS) overwrite files from the lapack
> installation?
>
> Certainly *if* two packages can affect the same files, their dependencies
> should reflect it, so for example, ATLAS depends on lapack,
That's certainly a valid question! We usually first install blas which produce
a libf77blas then lapack which will produce liblapack. Finally it is ATLAS's
turn. ATLAS if I am not mistaken overwrite libf77blas from blas purely and
simply. Then it takes liblapack and modifies it.
Note that the current plans that we have for blas/lapack/atlas with Volker
involves getting rid of the blas spkg and of the individual lapack spkg and
build {f77,c}blas and lapack in one go in the ATLAS spkg.
Francois
This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.
Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.
--
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
