Hi Stephen, On Monday 10 December 2007, Stephen Gran wrote: > So I was looking over the code base last night and wondering about > exercises to get myself a little more up to speed on it. One thing that > I noticed going through was that there seems to be quite a lot of > duplicate code spread through the shell scripts, and it seems like a > useful idea to start implementing a shell library. That could indeed be useful, but very much depends on where and how much. Can you give some examples? > I can't promise I'm actually going to get to doing this (my plate is > actually kind of full), but I wanted to ask for feedback before even > starting. I can see some obvious plusses (reduced disk usage, code > reuse, etc), but also at least two obvious issues (neither of which may > be showstoppers in practice). Disk usage is not the main concern here. As D-I completely runs in memory, the main concerns for something like this are: - initrd size (for different installation methods) - memory usage for loaded components - additional memory usage when running components One important issue is to try to avoid adding code into initrds that is not actually used there. It's better then to only load it when anna is run (the "load additional components" stage"). And of course which udebs go into an initrd and which are loaded later varies between installation methods. There are some components that will normally not be included in an initrd though (the exception being the "monolithic" method/image). > Most scripts that source bits from a shell library will end up loading > code that they don't use, and as far as I know, shell isn't as clever as > the linker in getting rid of unused functions. I don't imagine this is > a giant memory issue (I would imagine it might add a few K of runtime > useage to a lot of scripts, but I don't honestly know). Well, I'd imagine a central location with different function libraries and with those bits used by the same scripts kept together. And maybe a general "base" library with (short) generally useful functions. I certainly don't think you'd want to create a single huge function library file. > The second problem is just a practical one: where to put it? > libdebian-installer seems like the obvious place at first glance, but > maybe something else is set up earlier? It would only need to be > unpacked on disk relatively early to be useful. lib-di would be the one option. For functions that need to be available in initrds, rootskel could be another option. If they would be functions wrapping debconf functionality, cdebconf would probably be most logical. > Thoughts, comments, flames? I may also of course be completely missing > a similar thing already in the code base, but I didn't see it in my run > through last night. Note that I'm currently doing something similar for partman (see recent commits). That already used some function libraries which I've now brought together in /lib/partman/lib/ and for which I've done some restructuring. Up front I think it would make sense to keep partman largely separate from the rest of D-I. There probably is plenty of room for restructuring things within partman though. Cheers, FJP
Attachment:
signature.asc
Description: This is a digitally signed message part.