On Thu, 29 May 2003 12:48, Steve Kargl wrote:
> > You are describing how it happens now, not WHY it happens like that.
> The WHY is obvious.  The modules
>    (1) get rebuilt with the kernel.
>    (2) get installed with the kernel.
>    (3) get moved to /boot/kernel.old when a new kernel is installed.
>    (4) *Ideally*, if an API changes, the modules will be updated
>        by the developer/committer who breaks the modules; otherwise,
>        a person experiencing the breakage can ask for the commit to
>        be backed out. (Note, the *ideally* acknowledges that 64-bit
>        platforms seem to suffer API breakage more than ia32).
> > I think the existing solution has problems, and would prefer some
> > external hooks for 3rd party modules.
> If you mean "third party modules without available sources", then
>    (1) The module should work for whatever -RELEASE i for which it was
> built. (2) If you upgrade the OS, the module may or may not work.
>        (a) If it works, well aren't you lucky.
>        (b) If it doesn't work, then
>            (i)   Ask the vendor for an update.
>            (ii)  Hack around the breakage.
>            (iii) Downgrade to the *PROPER* -RELEASE.

No, I mean third party modules with available sources, but not necessarily up 
to scratch code wise, or license wise.

I think if the code is committed there is a much greater onus to make sure it 
doesn't break, and it incrases the load on everyone testing things.

My basic point is that people want to use 3rd party modules - they aren't 
committers so it's not like they can just wack some code into the repo. The 
alternative for them is manual patching or using the ports framework - this 
is OK but suffers integration problems.

I just want some way of rebuilding my 3rd party modules with my kernel that 
doesn't involve me having to jump through hoops :(

I don't see what the down side of rebuilding 3rd party modules with a 
buildkernel and friends is.

Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140  AE4B 319B 41F4 5D17 FDD5

[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to