>From Marius Mauch on Friday, 05 December, 2003:
>Hi,
>Seeing this "language war" on -dev I think I should say again that the
>component model should make us free from language restrictions. There is
>no sense in saying "we should use language XXX for portage-ng" as the
>goal should be that each component can be implemented in the best
>fitting language. So it should be possible to have the dependency
>resolver in prolog, the ebuild parser in perl, the frontend in python,
>the storage backend in C and so on. Instead of arguing about the "best"
>language for implementation we should discuss about the language for the
>_interface_ for the component interaction.
>Once we have decided on that we can start creating the global
>architecture that describes which components interact with each other,
>which components are mandatory or optional and so on. Later in that
>process we can specify the first function signatures and start
>implementing the individual components. Then and not earlier we have to
>choose the implementation language.
>I hope we can stop the "let's use XXX" discussion now.
While I agree that *language* itself is not immediately important,
critical distro infrastructure (e.g. dpkg, apt, rpm, emerge) MUST
be available when things break, or users will potentially break the
packaging system trying to get their box working again.
IMHO, such programs should have an absolute minimum dependency chain
in order to work. Optimal would be native machine binaries,
statically linked. That's my main concern with emerge at the present
time--if python breaks, I can no longer emerge until I go around the
portage system to bring it back up.
At the very least, there ought to be a native machine binary form of
a simple packaging system that understands how to work with portage
and install *binary* versions of the packages, in case the whole
build system is broken.
Yes, you can work around things with rescue floppies and the like, but
it's much, much more inconvenient than having a statically linked
binary that can install a binary version of the b0rked packages and get
you back compiling again. (has happened to me 2 times already in
half a year of gentooing).
A second benefit of statically linking is that trojaned libs won't get
used in the install/verify program. It's not much, but it's another
ring in the chainmail.
Of course, optimally for security, the integrity verification programs
ought to be on a read-only medium....
-Joseph
--
[EMAIL PROTECTED]
"We continue to live in a world where all our know-how is locked into
binary files in an unknown format. If our documents are our corporate
memory, Microsoft still has us all condemned to Alzheimer's."
--Simon Phipps, http://theregister.com/content/4/30410.html
--
[EMAIL PROTECTED] mailing list
