Longstanding issues: structs & standalone Erlang

[Bengt Kleberg]

On 2006-02-23 03:15, Romain Lenglet wrote:
...deleted
> Here is the same misunderstanding again...
> The proposal was *not* to use ./configure ; make ; make install 
> for deployment / installation, but for *building packages*, 
> which in turn can be deployed and installed.

i am sorry, but i have trouble understanding your terminology. what is 
the difference between *building packages* and ''deployed and installed''?


...deleted
> To make this possible, a common form for source packages provided 
> by developers must be defined, e.g. by including a configure 
> script and a Makefile in every source tarball.
> (Fredrik, you are right when writing that the configure script 
> must not necessarily be generated by GNU Autoconf...)

i belive that when you say that ''configure must not necessarily be 
generated by GNU Autoconf'' you still expect ''configure'' to behave 
exactly as if it had been generated by gnu autotools. correct?


> Nothing should prevent a packager to take a source Erlang 
> application, to build it by running the provided configure 
> script and Makefile rules, and to create a user-installable 
> package using any "pure-Erlang" packaging system you want: in 
> this scenario, end users of the package would not have to 
> install anything else than Erlang.

from what you have sofar written i think that you are creating a 
unneccessary distinction between ''packager'' and ''end users''. i 
belive that for some (pure) applications their needs are similar enough 
to treat them as one and the same.

i also think you want to force application developers to use a gnu 
development system, to make things simpler for yourself. even if other 
users of the ''application'' would have a harder time because of this 
requierment. i could be wrong again.


...deleted
> Yes, just like there is a point in having a pure Ruby system that 
> can deploy "pure" Ruby packages, and a pure Java system that can 
> deploy "pure" Java packages, and a pure Perl system that can 
> deploy "pure" Perl packages, and a pure Python system that can 
> deploy "pure" Python packages...
> (Sorry for the ironic tone... ;-))

no need to excuse yourself, i see no irony. i have repeatedly come to 
the understanding that cpan is a reason for the success of perl.


> I am just wondering how you can manage / upgrade applications on 
> a system with such a proliferation of incompatible packaging 
> systems?

how about if they are not packaging systems? what if they are deployment 
systems? and they knows how to tailor the ''application'' for a 
particular hardware, os and installation directory?
would it be such a nightmare for a ''professional packager'' to write 
the interface from his favored tool to these pure tools?
it would only need to be done once for each tool.


> Really, I am not against this idea. I just say that a pure Erlang 
> packaging system should not be imposed, and applications should 
> be delivered by developers in source form with a configure 
> script and a Makefile, and not in compiled form as a pure Erlang 
> installable package.

i agree about not imposing, but i do not want to have a gnu system imposed.
i think that a good erlang deployment system (for pure erlang 
applicaitons, etc) could handle uncompiled erlang.


...deleted

> And even packages containing binary native code could be deployed 
> using a packaging system in pure Erlang, there is no problem 
> with that.
> One issue would be to be able to have several versions of every 
> such package, one for every architecture / system, and the 
> system should be able to choose and install the right version on 
> a system. But this can be solved.

i do not understand why it is neccessary to have several packages if the 
  deploymenmt system can handle hardware, os and installation directory.


bengt