[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: on packahing on general and on contents of http://wiki.octave.org/OE
Re: on packahing on general and on contents of http://wiki.octave.org/OEP:pkg
Sun, 2 Dec 2012 00:52:45 -0800 (PST)
----- Original Message -----
> From: Carnë Draug <address@hidden>
> To: Sergei Steshenko <address@hidden>
> Cc: c. <address@hidden>; Rafael Laboissiere <address@hidden>; Ben Abbott
> <address@hidden>; Jordi Gutiérrez Hermoso <address@hidden>; Juan Pablo
> Carbajal <address@hidden>; "address@hidden" <address@hidden>
> Sent: Sunday, December 2, 2012 10:32 AM
> Subject: Re: on packahing on general and on contents of
> On 2 December 2012 01:42, Sergei Steshenko <address@hidden> wrote:
>> Now, say,
>> foo_package depends on doo_package
>> bar_package depends on dah_package
>> Where do doo_package and dah_package come from ?
> If doo_package and dah_package are not installed, then from nowhere.
> If they are, the proposal I wrote there suggests the following order:
> - load the latest version availale
> - load the local install of the package
> - load the global install of the package
> - load the package from the external .db, starting from the latest
> added in case there's more than one.
So, this is a _typical_ invitation for trouble. In production environment it
tooks us onece more than a day to just find out that a wrong version was used.
Search paths are more _evil_ than good.
The decision we made was:
either a thing is taken _exactly_ from the place it is supposed to be, or it is
not taken at all with a clear error message.
We did sometimes have to use search paths, and in those cases _unconditionally_
the search process was logged. I.e. the designers could _exactly_ know which
versions were taken from where.
The dependency problem I've described can be much more severe - in parenthesis
I write possible locations as user IDs:
foo1(myself) -> foo2(global, John) -> foo3(global, John, Paul, Mary) ->
foo4(global, Paul, Mary)
So, "scientifically" speaking, one has to define a mechanism of switching
inheritance (from which user to take) on per dependency tree node basis.
_Or_ to simplify things _drastically_ - just _one_ tree is created on per user
basis, and then it's the user's responsibility to populate the tree with
whatever he/she likes. And packages are taken _only_ from user's tree.
The initial tree can be automatically created from global one; user will
replace stuff in his/her tree as necessary.
The KISS principle.
Re: [Pkg-octave-devel] mkoctfile not installed in Wheezy, Thomas Weber, 2012/12/02