[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipcop-devel
Subject:    Re: [IPCop-devel] Why it might be too hard to work with ipcop.
From:       c.gatzemeier () web ! de
Date:       2004-07-26 8:39:23
Message-ID: 200407241233.05581.c.gatzemeier () tu-bs ! de
[Download RAW message or body]


Thanks for the respose, and the good questions!
I forwarded them to debian-custom and have appended some answers.

You probably already know that a custom patched kernel in debian is not the 
problem as using a source deb, aplying your desired patch packages and making 
a binary kernel package (mk-kpkg) out of it is the "debian way" of kernel 
compilation anyway.

It could work similar for other packages as well without you needing to do all 
the package maintanance.

Kind Regards,
Christian


From http://lists.debian.org/debian-custom/2004/07/msg00093.html :

---- Q: CDDing a heavily patching project (LFS based)   -----

> - simply add stack-smashing protection to Debian 
>   (patch glibc+gcc+kernel)

Well, you could ask the respective maintainers to include the patches in
the source package and make them activate when e.g. an evironment
variable is set (I believe the gcc package already ships one of those
security packages, although it's not applied by default)

> - is there a Debian http package that does not include every single
>   module for Apache that we're not interested in?

As long as we're talking about one extra package, that would be alright
I guess. There are a lot of httpd's in Debian, htppd-hardened (or
whatever) would be ok (even more so if it's supposed to be
stripped-down).

> - strip Debian with all necessary packages down to under 100MB ?
>   (that includes ADSL firmware, all software, cgi's, langs, etc.)
> - patch pppd with a patch because it doesn't work with a certain type
>   of DSL modem (same goes for at least 10 other packages)?

1. ADSL firmware is a grey-black area right now. Those would have to go
into non-free or are not distributable at all currently. Dunno how one
could integrate those nicely, but Debian as a whole needs to find a
solution here eventually.

2. Stripping down should be possible to a certain extent, by hacking
debootstrap, debian-installer, et al. [when you choose to use them to install]

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

> 1. ADSL firmware is a grey-black area right now. Those would have to go
> into non-free or are not distributable at all currently. Dunno how one
> could integrate those nicely, but Debian as a whole needs to find a
> solution here eventually.

This is still a place where derived distros have their place.  But a
derived distro can still be CDD-based.  A CDD can provide some "core"
that is within Debian, and only add the bits from outside Debian
(non-free being a prime example) that absolutely cannot work from
within.
------------


> but since we don't have a real need for package
> management (and I don't want to include a rpmdb + rpm binaries


Yes, no need for full apt or rpm support. That ipcop would not benefit from 
packaging maybe a half-truth though. Leaving aside that IPcop might benefit 
using a shared base, maybe more importantly  it would be nice if the ipcop 
work could could itself be easily shared with other projects again. For other 
(embedded) platforms for example.

Tiny but compatible formats like ipkg or udeb seem great for striped down 
distibutions. For example there exist two "debian" distributions running on 
handhelds ("familiar" and "intimate").

A router related debian based distro is "pebble".
http://www.nycwireless.net/pebble








-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id040&opĚk
_______________________________________________
IPCop-devel mailing list
IPCop-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipcop-devel

[prev in list] [next in list] [prev in thread] [next in thread]