This one time, at band camp, Frans Pop said: > 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? The first thing I saw when going through was output functions (log(), error(), warning() and similar are all reimplemented dozens of times). I'm sure I saw similar things in related sets of scripts, but I can't put my finger on it now. > > 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 Understood. > 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. Right, that was my idea as well. > > 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. gotcha. > > 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. That's partly what got me thinking about this sort of thing. OK, I'll give it a look and get back to people. -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature