help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Going to start Octave Package Management.


From: Sergei Steshenko
Subject: Re: Going to start Octave Package Management.
Date: Fri, 1 Feb 2019 16:33:32 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0


On 1/31/19 9:29 PM, Dildar Sk wrote:
Thanks a lot, I am going through the GSoC page. And trying to solve the
problems referred there(Just idea phase). If I am sure about improvement I
would try to implement.



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html



Julia folks have not deeply enough addressed the issue of package dependencies whose source is not in Julia language. Though I've stopped monitoring Octave package development, I think Octave folks haven't addressed the same issue deeply enough either.


Yesterday I was playing with Julia plotting, and my initial attempts failed because a couple Qt libraries was missing. Installing the libraries resolved the issue, but I needed to first conduct web search on error messages I've encountered.


This issue is a big can of fat worms - regardless of language. This is because to resolve the issue one would have to come up with a set of methods that allow to establish presence of the needed dependencies, and the methods would depend on OS and distro. I.e. even within Linux different distros may have different versioning and different packaging (by that I mean which files are included in which package) - let alone Windows, *BSD and MacOs.


And in Linux we have DEB, RPM, ArchLinux, Gentoo, Pogo Linux (they used to have and maybe still have a really nice packaging system with separate tree per package) packaging systems - for each packaging system we would have to implement a method to determine whether the needed non-native (i.e. in case of Octave not in Octave language, in case of Julia not in Julia language, etc) package is installed. And before that we need to implement methods mapping files to packages. I.e. if an Octave package needs libFoo.so, we'll need to implement methods mapping libFoo.so to PackageContaininglibFoo.

What I mean is that in the end I want Octave, Julia, etc packaging system to tell me: libFoo.so is missing, install PackageContaininglibFoo to resolve the problem.


For that matter, one can truly appreciate the destructive force of GNU Bazaar vs whatever Cathedral.


--Sergei.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]