Re: packages

Hi KP

Am 06.06.2015 um 01:34 schrieb kp kirchdoerfer:
> Hi Erich;
> 
> ...sorry for being late.
> 
> Am Dienstag, 2. Juni 2015, 10:44:39 schrieb Erich Titl:
>> Hi KP
>>
>> I am somewhat online again and I would like to get the upgrade thing
>> running (again). Looking at the packages repo I only see 5_0 and 5_1.
> 
> I haven't changed anything since your tests. Looking at git commit logs it 
> should be 5.1.4.
> 
> Could you try to cleanup the packages repo before 5.2? Or even add some notes 
> (e.g. the wiki) how to deal with the repository so it could be used to update 
> from via a command line tool?

Mhhh... never dealt with a Wiki as I hate the technology.

> As-Is is a bit confusing (yes I know it is mainly for testing now). 
> 
>> What is the actual content (5.1.x) of 5_1?
>> Will there be a 5_2 (5.2.x) sometime soon?
> 
> I just added 5.2-rc1 images to FRS at sourceforge.
> 
> Hopefully end of month a final version will be available.
> 
> It looks pretty stable, but I hope we can solve questions/issues  I found, 
> that would be worth to be solved before the final version, although they are no 
> showstoppers:
> 
> - do we need modules.tgz anymore? It adds a few MB to images...

I just needed modules.tgz to get the modules missing in the distros.

> 
> - hwdetect seems to search every time at boot the sqfs file and copies the 
> modules to /lib/modules. 

I don't like this idea at all.

Takes a long time to boot, and I prefer that after
> first boot and saving modules, it won't be searching any longer at boot. How do 
> we deal with additions in /etc/modules then? Currently (5.1.4) the file is used
> by hwdetect to find drivers in moduls.tgz, copies to /lib/modules, saved by the 
> user to modules.lro and they are available at next boot.

Much too complicated IMHO.
I still believe in moddb. hwdetect is fine, but fine tuning should be
possible. I might not even want to load certain drivers even if the
hardware is there.

> 
> - documentation of the boot process annd how to add modules etc should be 
> written for the wiki.
> I can help to make it into the wiki, but some more insights about using sqfs 
> would be better given by Andrew or you.

I am using the sqfs as I would use the modules tarball, just that it
remains compressed and thus fits also on a rather small architecture.

I somehow lost the old mail concerning upgrade and need to work from
memory (or the code) but it is rather simple.

In order to use upgrade we need a repository which holds the necessary
information in architecture, version, e.t.c. It is not really much, but
the actual package repository just does not provide it. I used branches
in the package repository to represent versions, as this does not use
any more space. I used files with information about latest and stable
releases and I rearranged the packages in the respecive branches to
bettter access a certain release. I also need kernel and initrd files
present in the package repository for upgrade. If you have a current
package repository you will see that it is rather simple.

Upgrade just takes what is installed on a machine and tries its best to
use upgrade to the requested level. When you build the packages there
should be a squashfs built along, I don't know now how it is named.

The most important thing about upgrade is stability in the naming
convention, we don't have one :-(

> 
> - will you be able to add your update stuff in time?

It was added and running until Andrew decided to do a name change to the
squashfs. Now I don't know.
Right now I am fighting with my hardware which does not want to access
the flash card reader from the virtual box environment, so I might not
be able to do much testing. I used to think virtual machines were useful
:-(

cheers

ET

------------------------------------------------------------------------------