I'm not sure if Dyne already behaves like this or not (so if it does then
I guess I'm asking for it to stay!) - One thing I'd like to see within
whatever structure is built, is the ability for new modules to over-rule
the built in ones. So for example, security updates can be released for
core components in between major releases. I imagine this would also make
it nice and easy to test new builds of different modules.

Cheers,

Dave

> Matt have the best tought :)
>
> d:b is a specialized distro for multimedia and most important is a nomad
> distro.
> One should not be bodered more than having the cd, a usb stick with the
> nest|modules and in case a usb drive with some data :)
> And with the tgz way is possible to make sure that everything is working
> before committing. Couple of rules or approval test should be discussed
> and written down. So for more than one person can maintain and test a
> module, as long as comments and changelogs are written :)
> There should be a discussion on what should be in the ramdisk and what
> in the sys; for example cups is in the sys, as my use of dyne I never
> used it, so I see it better in the text module, the wireless tools are
> in the sys but should not be better to configure the wifi-net from the
> ramdisk? That also could make possible to netboot with a floppy or usb
> stick within the wireless connection( here I could spent an hour in
> examples, having a small pc hanging nearby a projector or a mixer with
> connected just the vga|tv out and the electricity controlled via ssh -X )
>
> I'm writing down some notes, output of couple of find and ldd, I will
> post them tonite.
>
> fruity
>
> Matt Grice wrote:
>>> Looks good. just wanna add one thing.
>>>
>>> We should try to split up the modules in as many packages as possible
>>> so
>>> they'll get easier for many people to maintain. rigth now we got one
>>> for
>>> video, audio, net etc. I think it would be nice to have one for - say -
>>> video/veejay, video/editing, video/libs etc (same for audio). How
>>> 'bout
>>> that?
>>>
>> There's a potential problem here - each module is a squashfs filesystem.
>> What would be the overhead moving from several mounted squashfs
>> filesystems to several hundred?
>>
>> I think the best way would be to have a server that we can upload
>> "packages" to in .tgz format (a bit like a Slackware package), and when
>> maintenance on that module is finished, we just untar 'em and make the
>> module at the end, then moving the finished module into the main tree.
>>
>> Single package modules should be kept for only specialist software that
>> extends Dyne:Bolic.
>>
>> Whaddya think?
>>
>> Matt
>>
>>
>> _______________________________________________
>> dynebolic mailing list
>> dynebolic@???
>> http://lists.dyne.org/mailman/listinfo/dynebolic
>
>
> _______________________________________________
> dynebolic mailing list
> dynebolic@???
> http://lists.dyne.org/mailman/listinfo/dynebolic
>