Re: Multiple compile of source (ie, different configure lines for each package)

[Bastian Kleineidam]

> > On Wed, Sep 18, 2002 at 08:33:04AM +0200, Turbo Fredriksson wrote:
> > > I'm packaging Nagios. It builds tree packages from one source:
> > > 'nagios-text', 'nagios-pgsql' and 'nagios-mysql'. The differences
> > > is quite obvious: Compile the source three times, each time with 
> > > different ./configure options.
> > > 
> > > The problem I'm facing is that I want to 'scratch' the source
> > > after each build. Actually: build first package, move it aside,
> > > build second package - move it aside etc.

The ./configure as well as the make can be done in a target subdir, so
there is no need to scratch or clean the source tree.
You'll find a beautiful example of this at the fox package (libfox1.0
et al.)

Tschöö, Bastian
-- 
 Bastian Kleineidam

 reflexionsniveau AT web.de
   calvin AT users.sf.net
calvin AT debian.org



msg07176/pgp0.pgp
Description: PGP signature

Sponsor request: quelcom

[Devin Carraway]

I've packaged David Many'e's "Quelcom" suite of MP3 and WAV editing and
utility apps; I'm interested in finding a sponsor for them.

Quelcom has some overlap with the sox package, especially as concerns
its operations on wav files.  Where it differs is in its MP3 editing; it
can split and join mp3 files without re-encoding, and hence without any
further quality loss; so far as I'm aware there exists no package in
Debian capable of this.  It also provides some functionality not in sox,
such as report generation and integrity checks.  Nearly everything is
done using mmapped files, which makes it potentially much faster than
sox while remaining just as good for pushing every other process out
into swap for sake of the buffer cache.  :)

Quelcom should not be affected by MP3 patents, since it neither encodes
nor decodes.

Upstream is http://www.etse.urv.es/~dmanye/quelcom/quelcom.html; my
packages are at http://www.devin.com/debian/.  I've updated the manpages
to match the authoritative texinfo documentation, but it's otherwise
more or less unaltered.  I'd be interested in feedback if I screwed
anything up regarding the shared libraries.

-- 
Devin  \ aqua(at)devin.com, 1024D/E9ABFCD2;  http://www.devin.com
Carraway \ IRC: Requiem  GCS/CC/L s-:--- !a !tv C$ ULB+++$ O+@ P L+++



msg07177/pgp0.pgp
Description: PGP signature

Re: Sponsor request: quelcom

[Bas Zoetekouw]

Hi Devin!

You wrote:

> I've packaged David Many'e's "Quelcom" suite of MP3 and WAV editing and
> utility apps; I'm interested in finding a sponsor for them.

I'd be happy to sponsor you, if you are in the NM queue (or plan to
enter soon).

The copyright of the program is a bit unclear though. There is no
mention of copyright or license at all, except for a copy of the GPL
being in the upstream source. There is no mention that the software is
actually licensed under the GPL.

-- 
Kind regards,
+---+
| Bas Zoetekouw  | Het belangrijkste gereedschap|
|| van de theoretisch fysicus   |
| [EMAIL PROTECTED] | is de prullenbak.|
| [EMAIL PROTECTED] |   J.J. Lodder|
+---+ 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Multiple compile of source (ie, different configure lines foreach package)

[David Given]

On Wed, 2002-09-18 at 07:33, Turbo Fredriksson wrote:
[...]
> The key point was that there was no second point 1 (Touching file1-stamp).
> Since the 'file1-stamp' file where removed, I had expected 'make' to
> re-create it! It doesn't...
> 
> Any one have any idea?

make only looks at the file system *once*. So it sees that file1-stamp
doesn't exist, and runs the rule to create it. It will then assume that
file1-stamp will *continue* to exist. This has bitten me several times.

Personally, I'd be inclined to go for the easy solution: duplicate the
source tree three times, once for each configuration. Using symlink
trees this won't use much more disk space (apart from the object files),
and dependencies will keep working (although they're not used much in
Debian).

-- 
+- David Given --McQ-+ Did you hear about the hard-working but ill sage
|  [EMAIL PROTECTED]| who got cursed with garlic breath? He was a
| ([EMAIL PROTECTED]) | super-calloused fragile mystic hexed with
+- www.cowlark.com --+ halitosis.



signature.asc
Description: This is a digitally signed message part

Re: Multiple compile of source (ie, different configure lines for each package)

[Turbo Fredriksson]

Quoting wturkal <[EMAIL PROTECTED]>:

> Did you look at the packaging of netsaint, nagios's predecessor?

Ehh I'm the maintainer for Netsaint as well...

Netsaint never re-compiled the source...
-- 
Treasury [Hello to all my fans in domestic surveillance] toluene
smuggle Uzi nitrate South Africa nuclear Saddam Hussein Cuba DES
supercomputer Serbian 767 pits
[See http://www.aclu.org/echelonwatch/index.html for more about this]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Kernel module package depending on kernel-headers.

[Manoj Srivastava]

>>"Ian" == Ian Zimmerman <[EMAIL PROTECTED]> writes:

 Ian> The problem I have with the Debian module setup is that the
 Ian> resulting binary package is made to depend on the _exact_ kernel
 Ian> version (x.y.zz).  I know some modules require this, but most do not
 Ian> (after all, this is why we have MODVERSIONS, or?), so this is a waste
 Ian> of resources.  

Have you ever gotten that to work? I never have actually seen
 a working multiple kernel version module in the wild. And you can set
 up your module postinst to install the module in any directory you
 want -- /lib/modules/2.4/foo, for example, and copy files at will.

The module setup is quite flexible, really. What is lacking is
 that the determination of which kernel versions one can support is a
 module specific thing, and needs effort from the modules maintainer
 to hook into the framework provided. 

The modules people can add a postinst hook into the kernel
 image (by adding to /etc/kernel-img.conf) to have their script called
 whenever a new kernel image is installed -- and todo this magic, so
 that the kernel knows to load the module. Or thet can add to the
 search path for kernel when it looks for the modules.

But I guess it is easier to bitch about the infrastructure
 rather than figure out how to work with it.

manoj
-- 
 You may worry about your hair-do today, but tomorrow much peanut
 butter will be sold.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Kernel module package depending on kernel-headers.

[Ian Zimmerman]

Ian> The problem I have with the Debian module setup is that the
Ian> resulting binary package is made to depend on the _exact_ kernel
Ian> version (x.y.zz).  I know some modules require this, but most do
Ian> not (after all, this is why we have MODVERSIONS, or?), so this is
Ian> a waste of resources.

Manoj> But I guess it is easier to bitch about the infrastructure
Manoj> rather than figure out how to work with it.

I didn't mean to "bitch" - I am sincerely sorry if it sounded that
way.  This is a really hard problem, given that "upstream" in this
case is the union of the kernel hacker and module hacker collections.

Manoj> Have you ever gotten that to work? I never have actually seen a
Manoj> working multiple kernel version module in the wild.

Sure.  compressed loop and lmsensors, both seem to work with (at
least) 2.4.16 through 2.4.19 without recompile.  I remember in the bad
old days ftape also lasted me quite long.  And while I never tried to
maintain alsa this way (I dumped it and switched to OSS before I
started compiling modules myself again), I don't get the impression
that its authors expect it to be recompiled with each kernel
patchlevel upgrade.

I know there are modules which are tighly coupled with the kernel and
must be always recompiled, like the various trace kits.  But I think
they are the minority.

Manoj> And you can set up your module postinst to install the module
Manoj> in any directory you want -- /lib/modules/2.4/foo, for example,
Manoj> and copy files at will.

But what is the point of having them in a package, then?

Manoj> The modules people can add a postinst hook into the kernel
Manoj> image (by adding to /etc/kernel-img.conf) to have their script
Manoj> called whenever a new kernel image is installed -- and todo
Manoj> this magic, so that the kernel knows to load the module. Or
Manoj> thet can add to the search path for kernel when it looks for
Manoj> the modules.

Okay, I didn't know about the first part, thanks for pointing it out.
But it would only be of any import if the rigid dependencies were
relaxed. 

-- 
Ian Zimmerman, Oakland, California, U.S.A.
GPG: 433BA087  9C0F 194F 203A 63F7 B1B8  6E5A 8CA3 27DB 433B A087
EngSoc adopts market economy: cheap is wasteful, efficient is expensive.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Kernel module package depending on kernel-headers.

[Manoj Srivastava]

>>"Ian" == Ian Zimmerman <[EMAIL PROTECTED]> writes:

 Manoj> And you can set up your module postinst to install the module
 Manoj> in any directory you want -- /lib/modules/2.4/foo, for example,
 Manoj> and copy files at will.

 Ian> But what is the point of having them in a package, then?

Heh. I have 2.4.17 installed, and I install module_foo. Where
 do the module files go?

I now install 2.4.18. Now, either the module search path is
 changed, or boom! no more module foo with new kernel.

That is why the packaged module foo should copy files to 2.4.18

 Ian> Okay, I didn't know about the first part, thanks for pointing it out.
 Ian> But it would only be of any import if the rigid dependencies were
 Ian> relaxed. 

The rigid dependencies are created by people who package
 modules. They are there since it is a hassle to implement the hooked
 file copy stuff that is needed in order for packaged modules to work
 right. 

There really are reasons for the rigid dependendcies. We are
 not quite all morons here, you know. Even if we can't spell.

manoj
-- 
 I'm a lucky guy, and I'm happy to be with the Yankees.  And I want to
 thank everyone for making this night necessary. Yogi Berra at a
 dinner in his honor
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Request for sponsor: ITA of mysql-navigator

[Brian Nelson]

I'd like to adopt the mysql-navigator package so I'm looking for a
sponsor.  I've packaged the latest upstream source and cleaned up the
package a bit.  In particular, I've fixed the 2 RC bugs.

If anyone's interested, the packages can be found here:

deb http://bignachos.com/~nelson/debian/ ./
deb-src http://bignachos.com/~nelson/debian/ ./

-- 
People said I was dumb, but I proved them!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Multiple compile of source (ie, different configure lines for each package)

[Turbo Fredriksson]

I'm packaging Nagios. It builds tree packages from one source:
'nagios-text', 'nagios-pgsql' and 'nagios-mysql'. The differences
is quite obvious: Compile the source three times, each time with 
different ./configure options.

The problem I'm facing is that I want to 'scratch' the source
after each build. Actually: build first package, move it aside,
build second package - move it aside etc.

This because the build should be done as non-root, and the install
as root.

The problem is in the 'target depends' of the Makefile (debian/rules
in this case). A test makefile:

- s n i p -
file3: file1-stamp
@echo "3. In file3..."

file2:
@echo "2. Removing file1-stamp"
@rm file1-stamp

file1: file1-stamp
file1-stamp:
@echo "1. Touching file1-stamp"
@touch file1-stamp

test: file1 file2 file3
@echo "4. In test..."
- s n i p -

gives this output:
- s n i p -
tuzjfi:/tmp# make test
1. Touching file1-stamp
2. Removing file1-stamp
3. In file3...
4. In test...
- s n i p -


I _EXPECTED_:

- s n i p -
tuzjfi:/tmp# make test
1. Touching file1-stamp
2. Removing file1-stamp
1. Touching file1-stamp
3. In file3...
4. In test...
- s n i p -

The key point was that there was no second point 1 (Touching file1-stamp).
Since the 'file1-stamp' file where removed, I had expected 'make' to
re-create it! It doesn't...

Any one have any idea?
-- 
Cuba SDI BATF genetic president NSA SEAL Team 6 congress FBI FSF
iodine subway Soviet Albanian class struggle
[See http://www.aclu.org/echelonwatch/index.html for more about this]

Re: Multiple compile of source (ie, different configure lines for each package)

[Turbo Fredriksson]

when there is no longer anything to take away.
   -- Antoine de Saint-Exupery

Date: 18 Sep 2002 09:20:38 +0200
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Lines: 72
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Quoting Osamu Aoki <[EMAIL PROTECTED]>:

> On Wed, Sep 18, 2002 at 08:33:04AM +0200, Turbo Fredriksson wrote:
> > I'm packaging Nagios. It builds tree packages from one source:
> > 'nagios-text', 'nagios-pgsql' and 'nagios-mysql'. The differences
> > is quite obvious: Compile the source three times, each time with 
> > different ./configure options.
> > 
> > The problem I'm facing is that I want to 'scratch' the source
> > after each build. Actually: build first package, move it aside,
> > build second package - move it aside etc.
> 
> I would do waisteful buld as follows:
> 
> 1. copy sources to a subdirectory sub-1/
> 2. create 2 more by cp -a sub-1/ sub-2/
> 3. build 3 ./configure -with-whatever in each sub-?/
> 4. install to 3 locations to create 3 packages

I tried this the first time, but there's a problem with this.

Part of the 'rules' file:

- s n i p -
binary-nagios-text: $(patched)
dh_testdir -a

@( cd build-tree/nagios-[0-9]*/; \
   $(CONFIGURE); \
   set -e; $(MAKE) all && echo $?; \
   cd .. && mv nagios-[0-9]* ../binary/binary-nagios-text; \
)

binary-nagios-pgsql: $(patched)
dh_testdir -a

@( cd build-tree/nagios-[0-9]*/; \
   $(CONFIGURE) --with-pgsql-comments \
--with-pgsql-downtime \
--with-pgsql-extinfo \
--with-pgsql-retention \
--with-pgsql-status \
--with-pgsql-xdata; \
   set -e; $(MAKE) all && echo $?; \
   cd .. && mv nagios-[0-9]* ../binary/binary-nagios-pgsql; \
)
[...]
build: duplicate binary-nagios-text binary-nagios-pgsql binary-nagios-mysql
[empty target]

binary-arch: build install
[...]
- s n i p -

Both (actually there's three targets like this) depend on '$(patched).

The '$(patched)' part comes from 'debian/scripts/dbs-build.mk'
(see http://www.bayour.com/misc/dbs-build.mk.txt and 
http://www.bayour.com/misc/rules.txt).
This unpacks the source and patches it. This system is nice, because
I don't have to patch the pristine sources, I include the patches
separately in the 'debian/patches'...

But since the targets '$(STAMP_DIR)/created' and '$(STAMP_DIR)/unpack'
fullfills the FIRST time, it won't be done again. Therefor I'd like
to either REMOVE those files (that the targets creates) so that
'binary-nagios-pgsql' can be run properly. Or force 'make' to do
them any way. I've been playing with '.PHONY', but I can't get it
to work...
-- 
tritium Delta Force SEAL Team 6 Cuba FBI smuggle Ft. Meade Khaddafi
kibo munitions toluene nuclear domestic disruption Noriega AK-47
[See http://www.aclu.org/echelonwatch/index.html for more about this]

Re: Multiple compile of source (ie, different configure lines for each package)

[Bastian Kleineidam]

> > On Wed, Sep 18, 2002 at 08:33:04AM +0200, Turbo Fredriksson wrote:
> > > I'm packaging Nagios. It builds tree packages from one source:
> > > 'nagios-text', 'nagios-pgsql' and 'nagios-mysql'. The differences
> > > is quite obvious: Compile the source three times, each time with 
> > > different ./configure options.
> > > 
> > > The problem I'm facing is that I want to 'scratch' the source
> > > after each build. Actually: build first package, move it aside,
> > > build second package - move it aside etc.

The ./configure as well as the make can be done in a target subdir, so
there is no need to scratch or clean the source tree.
You'll find a beautiful example of this at the fox package (libfox1.0
et al.)

Tschöö, Bastian
-- 
 Bastian Kleineidam

 reflexionsniveau AT web.de
   calvin AT users.sf.net
calvin AT debian.org


pgp5F1fshdlDo.pgp
Description: PGP signature

Sponsor request: quelcom

[Devin Carraway]

I've packaged David Many'e's "Quelcom" suite of MP3 and WAV editing and
utility apps; I'm interested in finding a sponsor for them.

Quelcom has some overlap with the sox package, especially as concerns
its operations on wav files.  Where it differs is in its MP3 editing; it
can split and join mp3 files without re-encoding, and hence without any
further quality loss; so far as I'm aware there exists no package in
Debian capable of this.  It also provides some functionality not in sox,
such as report generation and integrity checks.  Nearly everything is
done using mmapped files, which makes it potentially much faster than
sox while remaining just as good for pushing every other process out
into swap for sake of the buffer cache.  :)

Quelcom should not be affected by MP3 patents, since it neither encodes
nor decodes.

Upstream is http://www.etse.urv.es/~dmanye/quelcom/quelcom.html; my
packages are at http://www.devin.com/debian/.  I've updated the manpages
to match the authoritative texinfo documentation, but it's otherwise
more or less unaltered.  I'd be interested in feedback if I screwed
anything up regarding the shared libraries.

-- 
Devin  \ aqua(at)devin.com, 1024D/E9ABFCD2;  http://www.devin.com
Carraway \ IRC: Requiem  GCS/CC/L s-:--- !a !tv C$ ULB+++$ O+@ P L+++


pgp8oKsIuctSr.pgp
Description: PGP signature

Re: Sponsor request: quelcom

[Bas Zoetekouw]

Hi Devin!

You wrote:

> I've packaged David Many'e's "Quelcom" suite of MP3 and WAV editing and
> utility apps; I'm interested in finding a sponsor for them.

I'd be happy to sponsor you, if you are in the NM queue (or plan to
enter soon).

The copyright of the program is a bit unclear though. There is no
mention of copyright or license at all, except for a copy of the GPL
being in the upstream source. There is no mention that the software is
actually licensed under the GPL.

-- 
Kind regards,
+---+
| Bas Zoetekouw  | Het belangrijkste gereedschap|
|| van de theoretisch fysicus   |
| [EMAIL PROTECTED] | is de prullenbak.|
| [EMAIL PROTECTED] |   J.J. Lodder|
+---+ 

Re: Multiple compile of source (ie, different configure lines for each package)

[David Given]

On Wed, 2002-09-18 at 07:33, Turbo Fredriksson wrote:
[...]
> The key point was that there was no second point 1 (Touching file1-stamp).
> Since the 'file1-stamp' file where removed, I had expected 'make' to
> re-create it! It doesn't...
> 
> Any one have any idea?

make only looks at the file system *once*. So it sees that file1-stamp
doesn't exist, and runs the rule to create it. It will then assume that
file1-stamp will *continue* to exist. This has bitten me several times.

Personally, I'd be inclined to go for the easy solution: duplicate the
source tree three times, once for each configuration. Using symlink
trees this won't use much more disk space (apart from the object files),
and dependencies will keep working (although they're not used much in
Debian).

-- 
+- David Given --McQ-+ Did you hear about the hard-working but ill sage
|  [EMAIL PROTECTED]| who got cursed with garlic breath? He was a
| ([EMAIL PROTECTED]) | super-calloused fragile mystic hexed with
+- www.cowlark.com --+ halitosis.


signature.asc
Description: This is a digitally signed message part

Re: Multiple compile of source (ie, different configure lines for each package)

[Turbo Fredriksson]

Quoting wturkal <[EMAIL PROTECTED]>:

> Did you look at the packaging of netsaint, nagios's predecessor?

Ehh I'm the maintainer for Netsaint as well...

Netsaint never re-compiled the source...
-- 
Treasury [Hello to all my fans in domestic surveillance] toluene
smuggle Uzi nitrate South Africa nuclear Saddam Hussein Cuba DES
supercomputer Serbian 767 pits
[See http://www.aclu.org/echelonwatch/index.html for more about this]

Re: Kernel module package depending on kernel-headers.

[Manoj Srivastava]

>>"Ian" == Ian Zimmerman <[EMAIL PROTECTED]> writes:

 Ian> The problem I have with the Debian module setup is that the
 Ian> resulting binary package is made to depend on the _exact_ kernel
 Ian> version (x.y.zz).  I know some modules require this, but most do not
 Ian> (after all, this is why we have MODVERSIONS, or?), so this is a waste
 Ian> of resources.  

Have you ever gotten that to work? I never have actually seen
 a working multiple kernel version module in the wild. And you can set
 up your module postinst to install the module in any directory you
 want -- /lib/modules/2.4/foo, for example, and copy files at will.

The module setup is quite flexible, really. What is lacking is
 that the determination of which kernel versions one can support is a
 module specific thing, and needs effort from the modules maintainer
 to hook into the framework provided. 

The modules people can add a postinst hook into the kernel
 image (by adding to /etc/kernel-img.conf) to have their script called
 whenever a new kernel image is installed -- and todo this magic, so
 that the kernel knows to load the module. Or thet can add to the
 search path for kernel when it looks for the modules.

But I guess it is easier to bitch about the infrastructure
 rather than figure out how to work with it.

manoj
-- 
 You may worry about your hair-do today, but tomorrow much peanut
 butter will be sold.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Kernel module package depending on kernel-headers.

[Ian Zimmerman]

Ian> The problem I have with the Debian module setup is that the
Ian> resulting binary package is made to depend on the _exact_ kernel
Ian> version (x.y.zz).  I know some modules require this, but most do
Ian> not (after all, this is why we have MODVERSIONS, or?), so this is
Ian> a waste of resources.

Manoj> But I guess it is easier to bitch about the infrastructure
Manoj> rather than figure out how to work with it.

I didn't mean to "bitch" - I am sincerely sorry if it sounded that
way.  This is a really hard problem, given that "upstream" in this
case is the union of the kernel hacker and module hacker collections.

Manoj> Have you ever gotten that to work? I never have actually seen a
Manoj> working multiple kernel version module in the wild.

Sure.  compressed loop and lmsensors, both seem to work with (at
least) 2.4.16 through 2.4.19 without recompile.  I remember in the bad
old days ftape also lasted me quite long.  And while I never tried to
maintain alsa this way (I dumped it and switched to OSS before I
started compiling modules myself again), I don't get the impression
that its authors expect it to be recompiled with each kernel
patchlevel upgrade.

I know there are modules which are tighly coupled with the kernel and
must be always recompiled, like the various trace kits.  But I think
they are the minority.

Manoj> And you can set up your module postinst to install the module
Manoj> in any directory you want -- /lib/modules/2.4/foo, for example,
Manoj> and copy files at will.

But what is the point of having them in a package, then?

Manoj> The modules people can add a postinst hook into the kernel
Manoj> image (by adding to /etc/kernel-img.conf) to have their script
Manoj> called whenever a new kernel image is installed -- and todo
Manoj> this magic, so that the kernel knows to load the module. Or
Manoj> thet can add to the search path for kernel when it looks for
Manoj> the modules.

Okay, I didn't know about the first part, thanks for pointing it out.
But it would only be of any import if the rigid dependencies were
relaxed. 

-- 
Ian Zimmerman, Oakland, California, U.S.A.
GPG: 433BA087  9C0F 194F 203A 63F7 B1B8  6E5A 8CA3 27DB 433B A087
EngSoc adopts market economy: cheap is wasteful, efficient is expensive.

Re: Kernel module package depending on kernel-headers.

[Manoj Srivastava]

>>"Ian" == Ian Zimmerman <[EMAIL PROTECTED]> writes:

 Manoj> And you can set up your module postinst to install the module
 Manoj> in any directory you want -- /lib/modules/2.4/foo, for example,
 Manoj> and copy files at will.

 Ian> But what is the point of having them in a package, then?

Heh. I have 2.4.17 installed, and I install module_foo. Where
 do the module files go?

I now install 2.4.18. Now, either the module search path is
 changed, or boom! no more module foo with new kernel.

That is why the packaged module foo should copy files to 2.4.18

 Ian> Okay, I didn't know about the first part, thanks for pointing it out.
 Ian> But it would only be of any import if the rigid dependencies were
 Ian> relaxed. 

The rigid dependencies are created by people who package
 modules. They are there since it is a hassle to implement the hooked
 file copy stuff that is needed in order for packaged modules to work
 right. 

There really are reasons for the rigid dependendcies. We are
 not quite all morons here, you know. Even if we can't spell.

manoj
-- 
 I'm a lucky guy, and I'm happy to be with the Yankees.  And I want to
 thank everyone for making this night necessary. Yogi Berra at a
 dinner in his honor
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C