Re: [gentoo-dev] Portage-NG implementation language(s)

[Joseph Pingenot]

>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


-- 
trelane@××××××××××.net--------------------------------------------------
"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

--
gentoo-dev@g.o mailing list