Re: packages

06.06.2015 10:39, Erich Titl пишет:
> 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.
>
/etc/modules.conf - just add `blacklist modulename`
>> - 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
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> leaf-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


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

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