Gentoo Archives: gentoo-dev

From: Joseph Pingenot <trelane@××××××××××.net>
To: Marius Mauch <genone@g.o>
Cc: gentoo-portage-dev@g.o, gentoo-dev@g.o
Subject: Re: [gentoo-dev] Portage-NG implementation language(s)
Date: Fri, 05 Dec 2003 11:33:12
In Reply to: [gentoo-dev] Portage-NG implementation language(s) by Marius Mauch
1 >From Marius Mauch on Friday, 05 December, 2003:
2 >Hi,
3 >Seeing this "language war" on -dev I think I should say again that the
4 >component model should make us free from language restrictions. There is
5 >no sense in saying "we should use language XXX for portage-ng" as the
6 >goal should be that each component can be implemented in the best
7 >fitting language. So it should be possible to have the dependency
8 >resolver in prolog, the ebuild parser in perl, the frontend in python,
9 >the storage backend in C and so on. Instead of arguing about the "best"
10 >language for implementation we should discuss about the language for the
11 >_interface_ for the component interaction.
12 >Once we have decided on that we can start creating the global
13 >architecture that describes which components interact with each other,
14 >which components are mandatory or optional and so on. Later in that
15 >process we can specify the first function signatures and start
16 >implementing the individual components. Then and not earlier we have to
17 >choose the implementation language.
18 >I hope we can stop the "let's use XXX" discussion now.
20 While I agree that *language* itself is not immediately important,
21 critical distro infrastructure (e.g. dpkg, apt, rpm, emerge) MUST
22 be available when things break, or users will potentially break the
23 packaging system trying to get their box working again.
24 IMHO, such programs should have an absolute minimum dependency chain
25 in order to work. Optimal would be native machine binaries,
26 statically linked. That's my main concern with emerge at the present
27 time--if python breaks, I can no longer emerge until I go around the
28 portage system to bring it back up.
29 At the very least, there ought to be a native machine binary form of
30 a simple packaging system that understands how to work with portage
31 and install *binary* versions of the packages, in case the whole
32 build system is broken.
33 Yes, you can work around things with rescue floppies and the like, but
34 it's much, much more inconvenient than having a statically linked
35 binary that can install a binary version of the b0rked packages and get
36 you back compiling again. (has happened to me 2 times already in
37 half a year of gentooing).
38 A second benefit of statically linking is that trojaned libs won't get
39 used in the install/verify program. It's not much, but it's another
40 ring in the chainmail.
41 Of course, optimally for security, the integrity verification programs
42 ought to be on a read-only medium....
44 -Joseph
47 --
48 trelane@××××××××××.net--------------------------------------------------
49 "We continue to live in a world where all our know-how is locked into
50 binary files in an unknown format. If our documents are our corporate
51 memory, Microsoft still has us all condemned to Alzheimer's."
52 --Simon Phipps,
54 --
55 gentoo-dev@g.o mailing list