Am Montag, 30. März 2015, 16:40:01 schrieb Erich Titl: > Am 30.03.2015 um 16:10 schrieb kp kirchdoerfer: > > Hi Erich; > > > > I disagree with a few of your decisions, mainly because they put a lot of > > extra work upon the dude instead get it once forever right in the upgrade > > script. I'll explain in the text... > > > > Am Montag, 30. März 2015, 15:33:48 schrieb Erich Titl: > >> Hi Folks > >> > >> I adapted the 5.1.4-rc1 branch in the package repository to provide all > >> necessary data to upgrade. > >> > >> the main differences to the existing packages are > >> > >> - modules-$ARCH.tgz tarballs are unpacked into module-$ARCH directories, > > > > extra work... > > Not really, even less work as you don't even need to build the tarball > :-) After system build the modules are in a > :
are in a ? > > I prefer you load the tarball, which is easier to maintain during a > > release > > and use re-use hwdetect on the router. > > No way, the tarball is just too big. It might too big for less than xxMB RAM, but it isn't too big itself :) > >> this makes no big difference in size, as the modules are compressed > >> anyway. The tarballs can be deleted. > >> - each modules-$ARCH directory has a modules.list file which is just the > >> result of 'find kernel' > >> - the firmware tarball is unpacked in a firmware directory one level > >> above the arch directories. The firmware is architecture independent, so > >> it does not make much sense to store it multiple times. > > > > True but also extra work, maybe there is a better solution which can be > > added to the upgrade script (the firmware to load is in /lib/firmware) > > This could be done in the upgrade script, but it would be a lot better > to update the installation routine when building a new packages version. > Redundancy eats storage at sourceforge. > > >> - the kernel version numbers are removed from the kernel file names. > >> There is no way for upgrade to guess the version number, so we need a > >> generic name for the kernel files. > > > > A lot of extra work; > > Not really. As of now there are no kernel files nor initrd or initmod. > This has to be provided in any case, so why not just install them with > more generic names. This requires a lot rework of the toolchains. I don't see anyone who can accomplish this task right now. I also believe that a new feature like upgrades, shouldn't make assumptions about a rework of a long-proven process, nor it should make the assumption that someone will work around the issues until the process has been fixed. > > And why do you even need the version? Just remove the suffix from > > linux-xxx. > I don't need the version, that is why I removed it. The version is just > there (was just there as the way the stable directory was set up). If > there is no version number in the future I am fine. Remove it when downloaded by the script, otherwise it has to be done manually for each release. > > Similar is true for moddb-xxx.lrp, just remove the version when storing > > the > > file. > > No, because upgrade builds moddb.lrp on the fly based on the modules > loaded in the running kernel. I don't care about a prebuilt moddb.lrp. This could lead to errors, you can foresee yet. See Andrews remarks. I think a longterm solution shouldn't neglect the pre-built moddb.lrp. As I wrote before, the upgrade process may make use of hwdetect. > Just FYI > > I just upgraded my two radio wireless router as this is my test bench. > Due to weak radio conditions it took quite a while, but the new kernel > booted. The initrd version in 5.1.4-rc1 is still 5.1.3, possibly a > glitch. Anyway it runs fine after an upgrade using sourceforge. Great progress of course! kp ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
