Re: LEAF upgrade

09.04.2015 14:35, Erich Titl пишет:
> Am 09.04.2015 um 11:12 schrieb Andrew:
>> Hi.
>>
> ...
>
>> For me, it's much easier to update just one file instead of hundreds of
>> modules on persist storage. Esp. when one broken (non-updated) module
>> can break system.
> You can't be serious. If we upgrade, we upgrade the kernel, initrd,
> initmod and of course the kernel modules plus all installed user level
> packages. This is what upgrade does. Nobody is forced to use it. And,
> btw. broken modules exist even inside tarballs :-(
You proposed to fetch all 1236 modules (5.1 branch, i686 release) during 
upgrade file-by-file? I think that it's a really bad idea.
Or you proposed to fetch only modules that are currently loaded by 
kernel? This is also a bad idea, it'll cause a great headache in future, 
when somebody will try to install new wireless (or other) card to his box.
>
>> So let's leave modules updating for tiny embedded systems which can't
>> fit module package.
> Why should we? Just because you don't like a directory tree?
Let's calculate. 1236 files on FS with cluster size=4kb will result in 
average 2kb per file overhead, or more than 2MB wasted storage space.
Then, wget takes usually near 0.5 sec per file to connect&get (ftp) - so 
modules updating will require near 10 minutes. Or more.
Then, if wget fails on some enough critical module (for ex., library) - 
you'll get a broken module dir (modules are here, but part of them are 
unusable because one dependent module is compiled for other kernel) and 
a big headache if this module is required by driver for NIC that is 
connected to Internet.
> We can either use the unpacked tarball (then I doubt the necessity of
> the tarball as a whole) or use a squashfs. If we decide for the squashfs
> then we ned to adapt a few more things. The unpacked tarball is easier
> because a trained monkey can handle it. You have a directory tree before
> it is tarballed and compressed (which I consider work) Let's not forget,
> this is a programmable computer.
How many people will require custom kernel modules?
How many of them will get this module from 3rd-party sources, not by 
compiling module for their kernel?
And for that people we can (ad must) leave moddb - just shrink from 
moddb all modules from squashfs.
>>> On the downside squashfs needs adaptation of busybox and the kernel.
>>> Also we need to create the squashfs files when building the package
>>> directory on the server.
>> Just kernel. AFAIK squash file doesn't need something special for it's
>> mount.
> That is just part of the story. Busybox mount squashfs needs to be enabled.
>
>>> We need to decide
>>>
>>> - do we really need a single file for the modules on the server?
>>> - is a compressed tarball or a squashfs the right solution if there is
>>> to be a single file?
>> Is there a better alternatives than tarball/squashfs for single modules
>> package?
> I don't care for either. I can live with a squashfs, but it means that
> you can only access these files on a system that supports it. I can live
> with that, can everybody?
Why not? Custom modules may (and should) be placed into r/w package like 
moddb.
> ...
>
>> Historically tarball was used because modules were uncompressed.
> In the real old days there was a module directory on the iso files. But
> this was much smaller.
>
> cheers
>
> ET
>
>
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>
>
> _______________________________________________
> leaf-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/leaf-devel

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

_______________________________________________
leaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/leaf-devel