Hello Erich, >> >> That's not true, every module is placed in modules.lrp (repository) and >> packages are "stand-alone". A module will change with every kernel >> upgrade, which isn't true for a package like ipsec. You will also get >> crazy if your package has to be updated with every release, besides >> from a maintanance viewpoint it's also a crime. > > Mhhh... can't really agreee, a package that needs a certain kernel > module has to provide that module unless you have some kind of dependency > mechanism. Opinions are free :-) > Why? In the case of ipsec an user can also add different ipsec modules like aes and the like for added functionality. Should they all be put in the base ipsec package and add a lot of size? The same for pppd/pppoe/pppoatm and there are numerous other examples.
IMHO it's easier to just update modules.lrp/kernel itself with a kernel upgrade then to update numerous package which all contain kernel modules (which aren't compatible with a newer kernel) and reconfigure each package. Most users doesn't know if a package contains a module and probably don't know why a program doesn't work anymore. It's easier and more consistent with one modules.lrp. Also, Arne Bernin has an updgrade tool for modules.lrp he posted the link some time ago to this list. You can just copy your /etc/modules to it and a new modules.lrp (with correct dependencies) is created for the new kernel version. >From a maintanance viewpoint it's also a crime to constantly recreate packages and put them in CVS when only a kernel version changes. > > >> >>>> Besides, you can also lzma your programs and have the same space >>>> savings. >>> >>> What about libraries? >>> >>> >> >> What about them? Libraries don't take much space and are shared with >> multiple programs. besides they are always needed so loaded in memory >> anyway. > > Why don't they take much space? They are on RAM disk and unless > Nathanael is right and they are _not_ copied to memory.... > They are copied to memory, programs use them (constantly) so they must be available in memory. >> >> >>>> How do you see a way to create f.e. bin.cfs and still be able to >>>> install packages? >>> >>> Packages should consist mostly of configuration data. Backing up, for >>> example, root.lrp is most of the time a pain in the butt. The same >>> applies to initrd, ipsec, ssh and others. They are just big. Few >>> people need to change the full content of a .lrp file. Most often we >>> just configure /etc/network/interfaces and a small number of files in >>> /etc/shorewall. >>> >>> >> >> I know you mentioned that before, but config files can change between >> versions, meaning that with an update of the binaries you can get very >> strange results. This is really a maintanance nightmare and will remove >> the coupling between a program and its config file. Now it's an entety >> (consistent package). >> > > Mhhh.... maybe, but not so much of a maintenance problem but providing > upgrade tools :-) > An upgrade tool is perfectly capable of dealing with either option. So I don't see a need to split config from binaries. In the case of shorwall, where an upgrade tool would be of most help, the configuration isn't compatible between most releases so remove the coupling will make you very vulnerable for attacks (because of wrong config). But indeed an upgrade tool will be helpfull, but changing the packages (split) isn't necessary for such a tool. >> There is hardly any need to backup initrd and root, and like you >> mention most often we only change interfaces and shorewall, so you only >> have to backup etc.lrp and shorwall.lrp. > > I just don't like to have all these binaries and libraries _unprotected_ > and _uncompressed_ on RAM disk. > They are not unprotected ;) > And now I stop ranting > :)) > > cheers > > Erich > Eric ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
