Re: Kernel config dependencies?

--===============62543671785157118==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="=-A6bSMbh3ZSQOwrWHheai"


--=-A6bSMbh3ZSQOwrWHheai
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2003-07-02 at 21:22, Mark Bainter wrote:
> Mark Gordon [[email protected]] wrote:
> >>
> [snip interesting idea about kernel option dependencies in ebuilds]
> >
> > Warning that you don't have the required support would be reasonable,
> > however I don't think I would like having an ebuild mess with my kernel
> > configuration for the following reasons:
> >=20
> > 1) The package might be for use with a kernel I am testing but not the
> >    kernel I currently boot in to by default.
> >=20
> > 2) Some options in the kernel can be either deliberately or accidentall=
y
> >    incompatible with others, and only I am likely to know how I want
> >    such issues resolved.
> >=20
>=20
> I wholeheartedly agree with this.  I think the idea is interesting=20
> though.  I think instead of dependencies we should make it special
> instructions at the end of the ebuild...
>=20
> ***=20
> *** Note: This software requires I2C support in the kernel (CONFIG_I2C)
> ***       and this is not currently available in your kernel.  Please
> ***       be sure that this option is enabled in the kernel you=20
> ***       attempt to run the software on, or it will not run properly.
> ***
>=20
^^^^^^^^^^^^^
I agree with this. You should do it anyway. reguardless if you check for
the module checking.

definatly also a limitation of portage .. is that theres not some
message levels you can pass back to portage as a package manager so that
when you do a -u world. at the end ( or when it bombs) the packages that
need to tell you somthing can :P=20

just a side note I was reminded of while reading this :P



> > 3) Assuming everything is OK I still need to know about the required
> >    option and do manual rebuilds because I generally have an overlap of
> >    at least a couple of weeks before I uninstall the previous kernel
> >    after an upgrade.
> >=20
> > 4) Kernel options sometimes change name, or move, and I would imagine
> >    this is an even bigger issue between 2.4 and 2.5.
>=20
> I think maybe the best way to handle this is on a case by case basis.
> You can check for the module availability fairly easily, and most of
> the other options that would be important for software are probably
> able to be verified via the /proc interface.  I don't think there's
> a way you can query the running kernel for the options it was built
> with, and you can't assume /usr/src/linux/.config mirrors the current
> kernel. =20
>=20
> Well...there is that patch that makes the config available through
> /proc, but there's no guarantee a user will be running that.
>=20
> _______________________________________________
> Zynot-pkgmgr mailing list
> [email protected]
> http://lists.zynot.org/mailman/listinfo/zynot-pkgmgr

--=-A6bSMbh3ZSQOwrWHheai
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQA/A9Mc4rKvBkfUvb0RAnIJAKDFbIRF4kW+RgVjAWzATsmHKdzp+ACguiAQ
U4R9/vBVi6cBkxIunqZhmdc=
=It0j
-----END PGP SIGNATURE-----

--=-A6bSMbh3ZSQOwrWHheai--


--===============62543671785157118==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Zynot-pkgmgr mailing list
[email protected]
http://lists.zynot.org/mailman/listinfo/zynot-pkgmgr

--===============62543671785157118==--