[gentoo-dev] Speaking of new kernels being added to the tree

[gentoo-dev] Speaking of new kernels being added to the tree

[Brad Laue]

Just reading the suse-sources thread - good idea, but I have a 
suggestion first.

I think we should wait on the inclusion of anything kernel related into 
the CVS tree until some more thought is put into how we're managing our 
kernel sources.

The kernel team seems to be both the smallest and most behind the times, 
and this is sad given that they're one of the most important teams 
involved in the project. We're two kernel versions behind (and don't 
justify that by claiming 2.4.21 or 2.4.22 had bugs, that doesn't fly), 
and show no signs of making it to a 2.4.23 release.

The kernel team needs more people. It needs to drastically reduce the 
number of kernels in the tree which are of a customized nature 
(xfs-sources, gs-sources, wolk-sources) until it can manage 
gentoo-sources in a timely fashion. The kernel team needs to build a 
subset of patches which form the core of the gentoo kernel. They then 
need to enable all the additional features provided by xfs-sources, 
wolk-sources and gs-sources on a per-use-flag basis, rather than having 
three kernels to manage, each with three different sets of incompatible 
patches. There obviously aren't enough resources to manage this.

Optionalizing features through the use of USE flags only makes sense. 
This is how all other things are done in Gentoo. I don't have nor do I 
intend to create six mozilla ports based on all the different sets of 
potentially incompatible USE flags present in the one ebuild, because to 
do so would make it impossible to manage. Why is the kernel any 
different? Why do many different people manage their own patchsets 
without collaborating and sharing resources to keep our official one up 
to date?

Brad.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Brad Laue]

Just to clarify the above with regard to xfs-sources, wolk-sources et 
al, rob in #gentoo-dev suggested that a wolk USE flag would collide with 
a number of gentoo-sources patches. These USE flags would be architected 
in such a way that enabling 'wolk' would work around such conflicts.

Many ebuilds do this; if a USE flag enables a feature with which another 
feature conflicts, the other feature must be disabled to compensate - 
shouldn't be much of a logistical problem.

Hope that clears that issue up,
Brad


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[C. Brewer]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

On Fri, 03 Oct 2003 05:54:09 -0400
Brad Laue <brad@gentoo.org> wrote:

> Many ebuilds do this; if a USE flag enables a feature with which another 
> feature conflicts, the other feature must be disabled to compensate - 
> shouldn't be much of a logistical problem.

Rather than use flags against the gentoo-sources...why not use flags against
the appropriate vanilla versions? Should clear up the tree a bunch, and then
you could have -
vanilla-sources (with use wolk,xfs,ck,etc)
dev-sources (with use mm,whatever)
gentoo-sources
ppc-sources
other-sources..
I know it'd be a bunch of work to change em over, but it'd leave the
gentoo-sources from getting clashed and should be easier to keep track of
one ebuild with different useflags than fifteen ebuilds..or it could be time
for my medication again:)



-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

On Fri, 2003-10-03 at 14:12, C. Brewer wrote:
> On Fri, 03 Oct 2003 05:54:09 -0400
> Brad Laue <brad@gentoo.org> wrote:
> 
> > Many ebuilds do this; if a USE flag enables a feature with which another 
> > feature conflicts, the other feature must be disabled to compensate - 
> > shouldn't be much of a logistical problem.
> 
> Rather than use flags against the gentoo-sources...why not use flags against
> the appropriate vanilla versions? Should clear up the tree a bunch, and then
> you could have -
> vanilla-sources (with use wolk,xfs,ck,etc)
> dev-sources (with use mm,whatever)
> gentoo-sources
> ppc-sources
> other-sources..
> I know it'd be a bunch of work to change em over, but it'd leave the
> gentoo-sources from getting clashed and should be easier to keep track of
> one ebuild with different useflags than fifteen ebuilds..or it could be time
> for my medication again:)

A problem is that people who release kernel patches do not do so at the
same time (e.g. Con Kolivas's second patchset for 2.4.22 is not released
at the same time as Alan Cox's third patchset for 2.4.22 etc etc, so the
version numbers would not work out properly for third-party patchsets,
and people wouldn't know when upgrades were available.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[C. Brewer]

[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]

On Fri, 03 Oct 2003 15:26:52 -0400
Donnie Berkholz <spyderous@gentoo.org> wrote:

> A problem is that people who release kernel patches do not do so at the
> same time (e.g. Con Kolivas's second patchset for 2.4.22 is not released
> at the same time as Alan Cox's third patchset for 2.4.22 etc etc, so the
> version numbers would not work out properly for third-party patchsets,
> and people wouldn't know when upgrades were available.

I had thought about that myself, and quite honestly figured two approaches-
bump a revision on patch changes, which would have the side effect of
forcing an upgrade on people who don't require it, or more realistically,
people using sources other than vanilla you would assume to be atleast
tracking the changes somewhat, so as to be notified via the patchmaker, or
if a little blurb was added to the changelog when a patch was updated.
Currently, I still track changes in the dev-sources by browsing kernel.org
every day, even though yall have consistently provided updated ebuilds darn
near immediately. So if there was maybe a little info blurb people could
look at to know when a patchset was updated, it would work out better with
the useflags.


-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

On Fri, 2003-10-03 at 20:41, C. Brewer wrote:
> On Fri, 03 Oct 2003 15:26:52 -0400
> Donnie Berkholz <spyderous@gentoo.org> wrote:
> 
> > A problem is that people who release kernel patches do not do so at the
> > same time (e.g. Con Kolivas's second patchset for 2.4.22 is not released
> > at the same time as Alan Cox's third patchset for 2.4.22 etc etc, so the
> > version numbers would not work out properly for third-party patchsets,
> > and people wouldn't know when upgrades were available.
> 
> I had thought about that myself, and quite honestly figured two approaches-
> bump a revision on patch changes, which would have the side effect of
> forcing an upgrade on people who don't require it, or more realistically,
> people using sources other than vanilla you would assume to be atleast
> tracking the changes somewhat, so as to be notified via the patchmaker, or
> if a little blurb was added to the changelog when a patch was updated.
> Currently, I still track changes in the dev-sources by browsing kernel.org
> every day, even though yall have consistently provided updated ebuilds darn
> near immediately. So if there was maybe a little info blurb people could
> look at to know when a patchset was updated, it would work out better with
> the useflags.
> 

Ahh, but part of the point of having a package management system (a
large part, IMHO) is so you _don't_ have to go track down the current
versions of things you run.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[C. Brewer]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

On Fri, 03 Oct 2003 22:05:59 -0400
Donnie Berkholz <spyderous@gentoo.org> wrote:
 
> Ahh, but part of the point of having a package management system (a
> large part, IMHO) is so you _don't_ have to go track down the current
> versions of things you run.

 Sure, but since most of the kernel is hands-on anyway,whats an extra
thirty secs user time, if it'll free up some space and dev time?:)



-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Brian Jackson]

On Friday 03 October 2003 04:36 am, Brad Laue wrote:
> Just reading the suse-sources thread - good idea, but I have a 
> suggestion first.
> 
> I think we should wait on the inclusion of anything kernel related into 
> the CVS tree until some more thought is put into how we're managing our 
> kernel sources.

That is the plan.

> 
> The kernel team seems to be both the smallest and most behind the times, 
> and this is sad given that they're one of the most important teams 
> involved in the project. We're two kernel versions behind (and don't 
> justify that by claiming 2.4.21 or 2.4.22 had bugs, that doesn't fly), 
> and show no signs of making it to a 2.4.23 release.

The team is behind the times or the releases are ;)
Seriously though, we are definitely in need of more people, and things are 
likely to continue to be slow until there are mroe people working on stuff.

> 
> The kernel team needs more people. It needs to drastically reduce the 
> number of kernels in the tree which are of a customized nature 
> (xfs-sources, gs-sources, wolk-sources) until it can manage 
> gentoo-sources in a timely fashion. The kernel team needs to build a 
> subset of patches which form the core of the gentoo kernel. They then 
> need to enable all the additional features provided by xfs-sources, 
> wolk-sources and gs-sources on a per-use-flag basis, rather than having 
> three kernels to manage, each with three different sets of incompatible 
> patches. There obviously aren't enough resources to manage this.

There will probably be a few -sources removed. But the decision of what is not 
made yet.

> 
> Optionalizing features through the use of USE flags only makes sense. 
> This is how all other things are done in Gentoo. I don't have nor do I 
> intend to create six mozilla ports based on all the different sets of 
> potentially incompatible USE flags present in the one ebuild, because to 
> do so would make it impossible to manage. Why is the kernel any 
> different? Why do many different people manage their own patchsets 
> without collaborating and sharing resources to keep our official one up 
> to date?

USE flags is a bad way to do things, lets say you have 116 patches (the latest 
pfeifer-sources does). If the 32nd patch is optional based on a use flag, it 
could take away parts that a later patch relies on, which would make the 
entire patchset fail. Now obviously this has been working since the current 
gentoo-sources and older pfeifer-sources does this, but it only works because 
all the patches have to be specially diffed in just the right order. At 
present time we don't have the manpower to do this.

> 
> Brad.
> 

On Friday 03 October 2003 04:54 am, Brad Laue wrote:
> Just to clarify the above with regard to xfs-sources, wolk-sources et 
> al, rob in #gentoo-dev suggested that a wolk USE flag would collide with 
> a number of gentoo-sources patches. These USE flags would be architected 
> in such a way that enabling 'wolk' would work around such conflicts.

actually if you applied the wolk patch, probably none of the gentoo-sources 
patches would apply. Not to mention that currently wolk and gentoo-sources 
are based on the same KV, but hopefully won't be for long.

> 
> Many ebuilds do this; if a USE flag enables a feature with which another 
> feature conflicts, the other feature must be disabled to compensate - 
> shouldn't be much of a logistical problem.

the many individual patch nature of -sources makes them unlike any other 
ebuild out there (not that I'm saying mozilla isn't a beast itself), many 
patches can touch the same 4 lines of the same file, which if the first one 
fails or isn't applied everything goes down hill from there.

--iggy

> 
> Hope that clears that issue up,
> Brad

> 
> --
> gentoo-dev@gentoo.org mailing list
> 
> 

-- 
Home -- http://www.brianandsara.net
Gentoo -- http://gentoo.brianandsara.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Brad Laue]

Brian Jackson wrote:
> USE flags is a bad way to do things, lets say you have 116 patches (the latest 
> pfeifer-sources does). If the 32nd patch is optional based on a use flag, it 
> could take away parts that a later patch relies on, which would make the 
> entire patchset fail. Now obviously this has been working since the current 
> gentoo-sources and older pfeifer-sources does this, but it only works because 
> all the patches have to be specially diffed in just the right order. At 
> present time we don't have the manpower to do this.
> 

Fair enough; three patchsets would probably equal the amount of work 
required to maintain three kernels. In that case maybe expanding 
gentoo-sources' patchset to cover the fundamentals (it's my 
understanding XFS among other things I'm after are in pfeifer-sources, 
it's just a matter of getting it out the door).

If grsec-sources and others do exist though, I think a lot of the 
gentoo-sources stuff should exist as a subset, though - when I switched 
from gentoo- to xfs-sources a great deal of iptables functionality was 
missing - thankfully grsecurity was still there, though.

Another good idea would be to document the content of the kernels on 
gentoo.org to make it easier to choose from.

Brad


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Brian Jackson]

On Friday 03 October 2003 11:23 am, Brad Laue wrote:
> Brian Jackson wrote:
> > USE flags is a bad way to do things, lets say you have 116 patches (the 
latest 
> > pfeifer-sources does). If the 32nd patch is optional based on a use flag, 
it 
> > could take away parts that a later patch relies on, which would make the 
> > entire patchset fail. Now obviously this has been working since the 
current 
> > gentoo-sources and older pfeifer-sources does this, but it only works 
because 
> > all the patches have to be specially diffed in just the right order. At 
> > present time we don't have the manpower to do this.
> > 
> 
> Fair enough; three patchsets would probably equal the amount of work 
> required to maintain three kernels. In that case maybe expanding 
> gentoo-sources' patchset to cover the fundamentals (it's my 
> understanding XFS among other things I'm after are in pfeifer-sources, 
> it's just a matter of getting it out the door).

livewire is supposed to start working on gs-sources again, though I don't know 
if it will have everything you are after.

> 
> If grsec-sources and others do exist though, I think a lot of the 
> gentoo-sources stuff should exist as a subset, though - when I switched 
> from gentoo- to xfs-sources a great deal of iptables functionality was 
> missing - thankfully grsecurity was still there, though.
> 
> Another good idea would be to document the content of the kernels on 
> gentoo.org to make it easier to choose from.

you mean like
http://www.gentoo.org/proj/en/kernel/kernel.xml
(linked of the project page, which is in turn linked off the fornt page)
and
http://www.gentoo.org/doc/en/gentoo-kernel.xml
(linked off the above kernel page)

> 
> Brad
> 
> 

-- 
Home -- http://www.brianandsara.net
Gentoo -- http://gentoo.brianandsara.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Brian Jackson]

On Friday 03 October 2003 11:16 am, Tim Yamin wrote:
> Brian Jackson wrote:
> > On Friday 03 October 2003 04:36 am, Brad Laue wrote:
> 
> > 
> >>The kernel team seems to be both the smallest and most behind the times, 
> >>and this is sad given that they're one of the most important teams 
> >>involved in the project. We're two kernel versions behind (and don't 
> >>justify that by claiming 2.4.21 or 2.4.22 had bugs, that doesn't fly), 
> >>and show no signs of making it to a 2.4.23 release.
> > 
> 
> True, but we have a pretty much bug-less product [current sources] [or 
> nearing there ;-) ]

That is very true and to be applauded, but in the linux world (and Gentoo 
specifically) you can't rest. You've got to be constantly supporting new 
hardware, new protocols, etc.

> 
> New patchset = lots of new problems, IMO... And because of the diversity 
> as a kernel, simple alpha-testing will NOT fix this.

That's why we have pfeifer-sources, which may be somewhat poorly named for 
people to figure out it's the "testing sources" is just that.

> 
> > 
> > The team is behind the times or the releases are ;)
> > Seriously though, we are definitely in need of more people, and things are 
> > likely to continue to be slow until there are mroe people working on 
stuff.
> > 
> > 
> >>The kernel team needs more people. It needs to drastically reduce the 
> >>number of kernels in the tree which are of a customized nature 
> >>(xfs-sources, gs-sources, wolk-sources) until it can manage 
> >>gentoo-sources in a timely fashion. The kernel team needs to build a 
> >>subset of patches which form the core of the gentoo kernel. They then 
> >>need to enable all the additional features provided by xfs-sources, 
> >>wolk-sources and gs-sources on a per-use-flag basis, rather than having 
> >>three kernels to manage, each with three different sets of incompatible 
> >>patches. There obviously aren't enough resources to manage this.
> > 
> 
> I don't really think so: the other kernels are managed by others [non 
> X86 devs] and things work fine there. Yes, we need more people, but what 
> I'm pledging here is that we need *quality* and *experienced* 
> [preferably with Gentoo and C/++] devs so that we don't get problems 
> with their collaboration and spend even more time than simply getting on 
> with it "as is".

We can't just keep getting on with it "as is", Gentoo users are notorious for 
liking life on the bleeding edge (and often times just the other side of it). 
the current gentoo-sources doesn't support nforce ide very well, it doesn't 
support sata, this list could get very long. Adding some of these features is 
not trivial. At some point it will become necessary to move forward to newer 
kernels.

> 
> > 
> > There will probably be a few -sources removed. But the decision of what is 
not 
> > made yet.
> > 
> 
> Like...? I'd be happy to take care of any which you are planning to scrap.

No, there are some that shouldn't have been there in the first place, there 
are some that shouldn't have time wasted on them, etc.

> 
> -- 
> 
> Tim Yamin [plasmaroo] :: Gentoo X86 Kernel Development
> plasmaroo@gentoo.org
> 

-- 
Home -- http://www.brianandsara.net
Gentoo -- http://gentoo.brianandsara.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Jon Portnoy]

On Fri, Oct 03, 2003 at 12:10:05PM -0500, Brian Jackson wrote:

> 
> That's why we have pfeifer-sources, which may be somewhat poorly named for 
> people to figure out it's the "testing sources" is just that.
> 

That's something that's always bugged me... what do you think of 
renaming that to make it clearer to users?

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 03 October 2003 03:34 pm, Brian Jackson wrote:
> On Friday 03 October 2003 04:36 am, Brad Laue wrote:
> USE flags is a bad way to do things, lets say you have 116 patches (the
> latest pfeifer-sources does). If the 32nd patch is optional based on a use
> flag, it could take away parts that a later patch relies on, which would
> make the entire patchset fail. Now obviously this has been working since
> the current gentoo-sources and older pfeifer-sources does this, but it only
> works because all the patches have to be specially diffed in just the right
> order. At present time we don't have the manpower to do this.
Or the patches could be converted to a format which would support multiple 
before cases. There may be a way to automate this, but it would need further 
investigation.

Another suggestion... Why not move away from -sources and make ebuilds based 
on genkernel (eg. sys-kernel/{,{gentoo,redhat,suse,...}-}linux). There would 
need to be something for manual configuration changes, but I believe 
genkernel already supports something like this. The only problem I can see is 
that it would end up recompiling the entire kernel for every configuration 
change, though that's a Portage bug that affects all ebuilds currently.
Is there any reason to install the kernel sources anymore and not do this?
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/fgtDZl/BHdU+lYMRAqk9AJ4nVudwqIsK5DCS0bLwE+vWC9vXEgCffE32
22fxqhkLblL/N0I+TZS9xR4=
=0Mqr
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

On Fri, Oct 03, 2003 at 11:50:15PM +0000 or thereabouts, Luke-Jr wrote:
> Another suggestion... Why not move away from -sources and make ebuilds based 
> on genkernel (eg. sys-kernel/{,{gentoo,redhat,suse,...}-}linux). There would 
> need to be something for manual configuration changes, but I believe 
> genkernel already supports something like this. The only problem I can see is 
> that it would end up recompiling the entire kernel for every configuration 
> change, though that's a Portage bug that affects all ebuilds currently.
> Is there any reason to install the kernel sources anymore and not do this?

I would be quite violently opposed to removing kernel sources entirely from
portage.  genkernel may be nice as an option for users who wish it.  Do not
force me to use it, however.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Jason Stubbs]

On Saturday 04 October 2003 08:58, Kurt Lieber wrote:
> On Fri, Oct 03, 2003 at 11:50:15PM +0000 or thereabouts, Luke-Jr wrote:
> > Another suggestion... Why not move away from -sources and make ebuilds
> > based on genkernel (eg. sys-kernel/{,{gentoo,redhat,suse,...}-}linux).
> > There would need to be something for manual configuration changes, but I
> > believe genkernel already supports something like this. The only problem
> > I can see is that it would end up recompiling the entire kernel for every
> > configuration change, though that's a Portage bug that affects all
> > ebuilds currently. Is there any reason to install the kernel sources
> > anymore and not do this?
>
> I would be quite violently opposed to removing kernel sources entirely from
> portage.  genkernel may be nice as an option for users who wish it.  Do not
> force me to use it, however.

Agreed. Genkernel would also prevent the addition of other patches by hand...

Jason

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 04 October 2003 12:01 am, Jason Stubbs wrote:
> Agreed. Genkernel would also prevent the addition of other patches by
> hand...
Same reply as I sent to klieber. =p
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/fi18Zl/BHdU+lYMRAnE3AJ9OS1v9Cua2eQ84AjZwQ65k5xhJ6QCfd121
JxUKq/4yc2AU6RFn/PCOZ6c=
=2GSn
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 03 October 2003 11:58 pm, Kurt Lieber wrote:
> I would be quite violently opposed to removing kernel sources entirely from
> portage.  genkernel may be nice as an option for users who wish it.  Do not
> force me to use it, however.
Is there any reason the Linux sources need to be included as an ebuild any 
more than, for example, the sources for Portage or Apache? You could always 
use ebuild to unpack into /var/tmp/portage and do the compile step yourself.
However, I do think it would be a good idea to have some way of installing the 
source for any ebuild into /usr/src. Maybe Portage can check and if the 
package name ends with -src, it trims it, only does an unpack and merges the 
- -src to /usr/src/ebuildname or something?
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/fhEgZl/BHdU+lYMRAhK0AJ9YDnNq5YcXWokerT92r/CB9QMcWgCfWGj7
FiqGOLvinUcPqov+5nkH6qA=
=Qv9+
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Jon Portnoy]

On Sat, Oct 04, 2003 at 12:15:00AM +0000, Luke-Jr wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Friday 03 October 2003 11:58 pm, Kurt Lieber wrote:
> > I would be quite violently opposed to removing kernel sources entirely from
> > portage.  genkernel may be nice as an option for users who wish it.  Do not
> > force me to use it, however.
> Is there any reason the Linux sources need to be included as an ebuild any 
> more than, for example, the sources for Portage or Apache? You could always 
> use ebuild to unpack into /var/tmp/portage and do the compile step yourself.
> However, I do think it would be a good idea to have some way of installing the 
> source for any ebuild into /usr/src. Maybe Portage can check and if the 
> package name ends with -src, it trims it, only does an unpack and merges the 
> - -src to /usr/src/ebuildname or something?

Yes. Because what you're suggesting is basically just to make genkernel 
default behavior - when the install guide already suggests using it.

You're not suggesting anything that provides a tangible benefit, you're 
just suggesting expanding our tree to do something we already do. That 
doesn't make sense.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 04 October 2003 02:25 am, Jon Portnoy wrote:
> You're not suggesting anything that provides a tangible benefit, you're
> just suggesting expanding our tree to do something we already do. That
> doesn't make sense.

As it is currently done, Portage cannot track the kernel itself, only the 
kernel sources. Also, it leaves the kernel in /usr/src/linux when it isn't 
really needed once installed except perhaps to save configuration (which 
genkernel has stuff for) and object files to speed future compilations (which 
Portage should do if you keep /var/tmp/portage around anyway).
It makes little sense to compile and install other packages but not compile 
and install Linux itself.
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/fkT7Zl/BHdU+lYMRAuehAJ9V2sIHEHUMJ6FuZysrEqjwtbLitwCglzM2
QucUeEDHkSuTzpSRGYbtpUk=
=ii4B
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Jason Stubbs]

On Saturday 04 October 2003 12:56, Luke-Jr wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 04 October 2003 02:25 am, Jon Portnoy wrote:
> > You're not suggesting anything that provides a tangible benefit, you're
> > just suggesting expanding our tree to do something we already do. That
> > doesn't make sense.
>
> As it is currently done, Portage cannot track the kernel itself, only the
> kernel sources. Also, it leaves the kernel in /usr/src/linux when it isn't
> really needed once installed except perhaps to save configuration (which
> genkernel has stuff for) and object files to speed future compilations
> (which Portage should do if you keep /var/tmp/portage around anyway).
> It makes little sense to compile and install other packages but not compile
> and install Linux itself.

Agreed. (My other post was written and sent to my local server before reading 
yours but took a while to get out)

However, having portage compile and install Linux has several issues. Portage 
would need  to be able to:
1) handle multiple saved configurations automatically.
2) update lilo/grub automatically _with_ backup.
3) extract the source to /usr/src if need be (as already mentioned)
4) handle different configurations of the same kernel version.

Tangible benefits that I can see:
1) ccache can be used in compiling the kernel automatically
2) a lot of disk space can be saved.

A lot of work would need to be done to do this successfully, though; maybe 
something that should be left for portage v3...

Jason

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Stuart Herbert]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1140 bytes --]

On Saturday 04 October 2003 5:29 am, Jason Stubbs wrote:
> A lot of work would need to be done to do this successfully, though; maybe
> something that should be left for portage v3...
>
> Jason

The day that Gentoo *forces* me to use a kernel auto-magically configured and 
compiled for me through an 'emerge' is the day that Gentoo joins my RedHat 
CDs in the bin.

Just because I'm emerged any particular set of kernel sources does *not* mean 
that a) I want that kernel adding to lilo/grub yet, and b) that my box has 
everything else in place to boot and run that kernel.

It's not broken, so please don't try to fix it.

Why can't this just be left alone?!?
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/
Come and meet me in March 2004                 http://www.phparch.com/cruise/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 04 October 2003 12:40 pm, Stuart Herbert wrote:
> The day that Gentoo *forces* me to use a kernel auto-magically configured
> and compiled for me through an 'emerge' is the day that Gentoo joins my
> RedHat CDs in the bin.
You could always 'emerge linux-src' if Portage were to add the -src suffix as 
I described.

>
> Just because I'm emerged any particular set of kernel sources does *not*
> mean that a) I want that kernel adding to lilo/grub yet,
I don't think it should modify the configurations, only a few symlinks that 
you can ignore if you choose to.

> and b) that my box
> has everything else in place to boot and run that kernel.
If you'd be compiling the kernel for another system, you could have Portage 
build only a GRP. As for local dependencies, the development-sources already 
depend on the module-init-tools needed to run them even though the sources 
don't actually need it. It might also be worth noting that often the time 
between a system update and etc-update, your system could in theory be 
unbootable were there to be a power failure.
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/fsblZl/BHdU+lYMRAuSaAJ9QLk7wuPkb21HqBZvPGw7DnHyBigCeJ6FP
lH08hf05LQ+46CMqLsDqRb0=
=LOnQ
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Stuart Herbert]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1726 bytes --]

On Saturday 04 October 2003 2:10 pm, Luke-Jr wrote:
> You could always 'emerge linux-src' if Portage were to add the -src suffix
> as I described.

And what would that give me?  The current range of sources in Portage gives me 
a nice selection of choice.  Personally, I'm very happy with it.

> I don't think it should modify the configurations, only a few symlinks that
> you can ignore if you choose to.

No thanks.

> If you'd be compiling the kernel for another system, you could have Portage
> build only a GRP. As for local dependencies, the development-sources
> already depend on the module-init-tools needed to run them even though the
> sources don't actually need it. 

And what about kernel modules that are required?  How will those get 
re-compiled?  You can't just re-emerge them, because they have this annoying 
habit of going and deleting the currently-installed version ...

> It might also be worth noting that often
> the time between a system update and etc-update, your system could in
> theory be unbootable were there to be a power failure.

I'm sorry, but I really do think that this idea is both stupid, and more 
trouble than it's worth.  Administrators have been managing their boxes just 
fine up to now.

Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/
Come and meet me in March 2004                 http://www.phparch.com/cruise/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 04 October 2003 01:51 pm, Stuart Herbert wrote:
> On Saturday 04 October 2003 2:10 pm, Luke-Jr wrote:
> > You could always 'emerge linux-src' if Portage were to add the -src
> > suffix as I described.
>
> And what would that give me?  The current range of sources in Portage gives
> me a nice selection of choice.  Personally, I'm very happy with it.
emerge linux-mm-src, then. or emerge linux-redhat-src, if you prefer.
>
> > I don't think it should modify the configurations, only a few symlinks
> > that you can ignore if you choose to.
>
> No thanks.
Just because you choose not to use it doesn't mean you should be forcing other 
people not to be able to. This provides the *option* to use it. Options are 
always best.
>
> > If you'd be compiling the kernel for another system, you could have
> > Portage build only a GRP. As for local dependencies, the
> > development-sources already depend on the module-init-tools needed to run
> > them even though the sources don't actually need it.
>
> And what about kernel modules that are required?  How will those get
> re-compiled?  You can't just re-emerge them, because they have this
> annoying habit of going and deleting the currently-installed version ...
That annoying habit is what should be fixed, then. Using a bug as a reason to 
not implement a feature isn't a good idea... =p
>
> > It might also be worth noting that often
> > the time between a system update and etc-update, your system could in
> > theory be unbootable were there to be a power failure.
>
> I'm sorry, but I really do think that this idea is both stupid, and more
> trouble than it's worth.  Administrators have been managing their boxes
> just fine up to now.
For the most part, what I am suggesting is adding options, not removing them. 
Where people used vanilla-sources in the past (which is quite vague actually; 
why should one assume -sources means it's Linux?), they would now simply be 
using linux-src. redhat-sources would be linux-redhat-src. Users who don't 
care to manually recompile their kernels could move over to using linux or 
linux-redhat. It would also let people emerge things such as kdelibs-src or 
apache-src if they wanted to.
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/ftODZl/BHdU+lYMRAro3AJ4qKFmVGfl8RI959sPi4oscZlodmACgit99
HfUTOcVhd2wq+fEssNKV9AA=
=60BZ
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Stuart Herbert]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2509 bytes --]

On Saturday 04 October 2003 3:04 pm, Luke-Jr wrote:

> emerge linux-mm-src, then. or emerge linux-redhat-src, if you prefer.

Sorry, but renaming packages always makes a mess of upgrades.  I've done it 
myself in the past, but I'm reluctant to do it again until Portage provides 
us with tools to automate the migration for users.

Besides, what value is there in adding 'linux-' in front of the different 
kernel names?  I know Gentoo's being ported to run on more than just the 
Linux kernel, but still.  Seems like change for change's sake.

> Just because you choose not to use it doesn't mean you should be forcing
> other people not to be able to. This provides the *option* to use it.
> Options are always best.

Simplicity is always best.  Options are good, but only when they add 
measurable value.  Or when they're just too cool to leave out ;-)

> That annoying habit is what should be fixed, then. Using a bug as a reason
> to not implement a feature isn't a good idea... =p

If it was that easy, I think someone would have fixed it by now ... ;-)  Tbh, 
the fix is probably just to slot the module, using a combination of the 
target kernel version and the module's version.

If what you're proposing are changes *just* to genkernel, then I don't really 
care what you do.  But you're talking like you're suggesting fundamental 
changes to the kernel ebuilds themselves.  *That's* what I'm objecting to ;-)

> For the most part, what I am suggesting is adding options, not removing
> them. Where people used vanilla-sources in the past (which is quite vague
> actually; why should one assume -sources means it's Linux?), 

Erm, because the package is actually called sys-kernel/vanilla-sources, 
perhaps? ;-)  And because the distribution is known as Gentoo Linux? ;-)

Seriously, I do see the problem you're describing.  But before you go around 
renaming packages, please implement a solution in Portage that will 
automatically handle 'emerge -u' when the package has been renamed.

Thanks,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/
Come and meet me in March 2004                 http://www.phparch.com/cruise/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 04 October 2003 02:15 pm, Stuart Herbert wrote:
> On Saturday 04 October 2003 3:04 pm, Luke-Jr wrote:
> > emerge linux-mm-src, then. or emerge linux-redhat-src, if you prefer.
>
> Sorry, but renaming packages always makes a mess of upgrades.  I've done it
> myself in the past, but I'm reluctant to do it again until Portage provides
> us with tools to automate the migration for users.
I thought Portage did automate renaming of packages? Isn't that what those 
Q#-YYYY are for?
>
> Besides, what value is there in adding 'linux-' in front of the different
> kernel names?  I know Gentoo's being ported to run on more than just the
> Linux kernel, but still.  Seems like change for change's sake.
Packages don't neccesarilly need to be a kernel at all. If -src were 
implemented, there would be apache-src, kdelibs-src, gcc-src, etc...
>
> > Just because you choose not to use it doesn't mean you should be forcing
> > other people not to be able to. This provides the *option* to use it.
> > Options are always best.
>
> Simplicity is always best.  Options are good, but only when they add
> measurable value.  Or when they're just too cool to leave out ;-)
As it is, kernels are a non-standard set of ebuilds. There is always value is 
standardizing things.
>
> > That annoying habit is what should be fixed, then. Using a bug as a
> > reason to not implement a feature isn't a good idea... =p
>
> If it was that easy, I think someone would have fixed it by now ... ;-) 
> Tbh, the fix is probably just to slot the module, using a combination of
> the target kernel version and the module's version.
w/o the module's version. You don't want to install ALSA 0.9.2 and 0.9.3 at 
the same time, do you?
>
> If what you're proposing are changes *just* to genkernel, then I don't
> really care what you do.  But you're talking like you're suggesting
> fundamental changes to the kernel ebuilds themselves.  *That's* what I'm
> objecting to ;-)
It would be making the linux ebuilds' src_compile actually do what it was 
meant to do. It would also be adding a feature to portage so one could append 
- -src to the end of any ebuild and get only the result of src_unpack in 
their /usr/src dir.

>
> > For the most part, what I am suggesting is adding options, not removing
> > them. Where people used vanilla-sources in the past (which is quite vague
> > actually; why should one assume -sources means it's Linux?),
>
> Erm, because the package is actually called sys-kernel/vanilla-sources,
> perhaps? ;-)  And because the distribution is known as Gentoo Linux? ;-)
IMO, categories are merely useful for when searching for packages and 
shouldn't really be needed for knowing what a package is especially since two 
packages cannot have the same name. If pkg name conflicts never happened, I'd 
suggest using only the package names where category/package is often used.
I refer to Gentoo as only Gentoo. When referring to my OS, I call it Gentoo 
GNU/Linux. I also make reference to Gentoo BSD, Gentoo OS X, or Gentoo GNU 
(HURD==completely GNU) occasionally.
Once Gentoo BSD or Gentoo OS X get to a usable stage, I'd assume the website 
would be updated to reflect that Gentoo is more than just Linux or perhaps 
seperate Gentoo BSD/OSX/etc websites would be setup.
>
> Seriously, I do see the problem you're describing.  But before you go
> around renaming packages, please implement a solution in Portage that will
> automatically handle 'emerge -u' when the package has been renamed.
AFAIK, this already should work. Note I don't use -u nor the world metakeyword 
(at least until Portage supports sticky USE), though.
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/ftr2Zl/BHdU+lYMRAkY6AJ9DncM6yOfqWDCuPB3U9by4Reg4nwCfX2GI
sVbRtUR2xiujxlj/WdRPpI8=
=v4Os
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Stuart Herbert]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2140 bytes --]

On Saturday 04 October 2003 3:36 pm, Luke-Jr wrote:
> Packages don't neccesarilly need to be a kernel at all. If -src were
> implemented, there would be apache-src, kdelibs-src, gcc-src, etc...

That could get messy.  What exactly is the problem that you're touting your 
solution for?

> As it is, kernels are a non-standard set of ebuilds. There is always value
> is standardizing things.

Yeah, but standardisation can become a goal in of itself, and that's not 
healthy.

> w/o the module's version. You don't want to install ALSA 0.9.2 and 0.9.3 at
> the same time, do you?

Probably not, no.  But cloop-0.68 isn't compatible with cloop-1.0, for 
example, and I would be interested in having both of those installed at the 
same time.

> It would be making the linux ebuilds' src_compile actually do what it was
> meant to do. 

Say's who? ;-)

> It would also be adding a feature to portage so one could
> append -src to the end of any ebuild and get only the result of src_unpack
> in their /usr/src dir.

Interesting, for sure.

> IMO, categories are merely useful for when searching for packages and
> shouldn't really be needed for knowing what a package is especially since
> two packages cannot have the same name. 

Is that true?  I thought the category was part of the package name.

> call it Gentoo GNU/Linux. 

I won't bite that troll-bait ;-)

> AFAIK, this already should work. Note I don't use -u nor the world
> metakeyword (at least until Portage supports sticky USE), though.

But have you personally tested it, or can you point me to somewhere where this 
behaviour is documented?  I don't like assumptions.

Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/
Come and meet me in March 2004                 http://www.phparch.com/cruise/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 04 October 2003 03:09 pm, Stuart Herbert wrote:
> That could get messy.  What exactly is the problem that you're touting your
> solution for?
How could it get messy? In theory, after src_unpack, /var/tmp/portage/*/work 
should be a source tree for the package.
>
> > It would be making the linux ebuilds' src_compile actually do what it was
> > meant to do.
> Say's who? ;-)
http://dictionary.com/search?q=compile
>
> > IMO, categories are merely useful for when searching for packages and
> > shouldn't really be needed for knowing what a package is especially since
> > two packages cannot have the same name.
> Is that true?  I thought the category was part of the package name.
If it were part of the package name, why aren't the database firebird and the 
browser firebird allowed to have the same name?
>
> > call it Gentoo GNU/Linux.
> I won't bite that troll-bait ;-)
Referring to my system running Linux for a kernel and using mostly GNU tools 
for everything else (C library; ls,cp,mv,sed)
>
> > AFAIK, this already should work. Note I don't use -u nor the world
> > metakeyword (at least until Portage supports sticky USE), though.
> But have you personally tested it, or can you point me to somewhere where
> this behaviour is documented?  I don't like assumptions.
Just because I think it is possible to do doesn't mean I know how to do it ;)
For example, I know it's possible to make a Java ebuild, but I don't know 
where to start for that.
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/fwF9Zl/BHdU+lYMRAgY/AJ9b4UET9INooy1yX5oJOUxmpIuJogCeIQcL
YA3OJdr5UwfBfwCGlaOMnlA=
=gJXf
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]

On 10/04/03  Luke-Jr wrote:

> > > IMO, categories are merely useful for when searching for packages
> > > and shouldn't really be needed for knowing what a package is
> > > especially since two packages cannot have the same name.
> > Is that true?  I thought the category was part of the package name.
> If it were part of the package name, why aren't the database firebird
> and the browser firebird allowed to have the same name?

They can have the same name for portage, but this should be avoided as
it is not transparent for users if they type "emerge firebird" which one
will be chosen.

> > > AFAIK, this already should work. Note I don't use -u nor the world
> > > metakeyword (at least until Portage supports sticky USE), though.
> > But have you personally tested it, or can you point me to somewhere
> > where this behaviour is documented?  I don't like assumptions.
> Just because I think it is possible to do doesn't mean I know how to
> do it ;) For example, I know it's possible to make a Java ebuild, but
> I don't know where to start for that.

How about the java and java-pkg eclasses?
The renaming of ebuilds is possible but requires manual work and still
creates some problems, so I recommend against it unless it's necessary.
The -src suffix for package names to select cource code installs would
require a major change to the package-name parsing code.

Personally I don't see any benefit from your proposal other that it will
require a lot of work, confuse users and create a lot of other problems
not thought of yet.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Patrick Börjesson]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

> Packages don't neccesarilly need to be a kernel at all. If -src were 
> implemented, there would be apache-src, kdelibs-src, gcc-src, etc...

That would mean that portage wouldn't be able to track the files
installed when doing a "make install" on those packages... As the
kernels don't install anything, but in /lib/modules/`uname -r` where the
kernel-modules go, portage doesn't have to track the files generated by
a kernel-compile. But to be able to remove files which ordinary packages
install portage has to be able to track the files installed by those
packages. This would mean that portage would have to be extensively
modified to be able to handle the files installed by a "make install"
from a package merged to /usr/src.
Just a thought...

Patrick Börjesson

-- 
Public key id: 4C5AB0BF
Public key available at search.keyserver.net[:11371]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 04 October 2003 03:56 pm, Patrick Börjesson wrote:
> That would mean that portage wouldn't be able to track the files
> installed when doing a "make install" on those packages... As the
> kernels don't install anything, but in /lib/modules/`uname -r` where the
> kernel-modules go, portage doesn't have to track the files generated by
> a kernel-compile. But to be able to remove files which ordinary packages
> install portage has to be able to track the files installed by those
> packages. This would mean that portage would have to be extensively
> modified to be able to handle the files installed by a "make install"
> from a package merged to /usr/src.
> Just a thought...
In theory, Portage could track them if ebuild could be modified to use /usr/
src/pkg when it existed instead of /var/tmp/portage/*/work and the 
application was installed via 'ebuild pkg merge'. I'm not sure how possible 
that would be for implementation, though.
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/fwOKZl/BHdU+lYMRAqTcAJ0e56vTbTmiQPT216LyFjnFCgG2BACfUHty
HOTJtpID3o1hsZek1664yvs=
=bY6v
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Patrick Börjesson]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

> In theory, Portage could track them if ebuild could be modified to use
> /usr/src/pkg when it existed instead of /var/tmp/portage/*/work and
> the application was installed via 'ebuild pkg merge'. I'm not sure how
> possible that would be for implementation, though.

But then the question is: Why? We already have the source unpacked in
/var/tmp/portage/*/work so why "move" it to /usr/src? There are already
ways for people to do the configure- and make-steps them selves if they
wish (through the ebuild-command as you yourself said). As I see it
there would be no advantage reimplementing it the proposed way...
As for the kernels to be auto-configured, why not do it the same way as
some other packages do it: have an extra section in the ebuild that
configures the kernel for you through genkernel... Several other
packages already have this section (think it's called config) including
postresql. This could be advertised in the same way as in the
postresql-ebuild at the end of the emerge-command, and thus everybody
has a choice in how they would like to configure and compile the kernel.

Patrick Börjesson

-- 
Public key id: 4C5AB0BF
Public key available at search.keyserver.net[:11371]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[William Kenworthy]

because a number of other packages want to see /usr/src/linux for the
running kernel.  lm-sensors, vmware, nvidia, ...

I do agree that some effort should be put into fixing the unwanted
effects that occur when you install another kernel though (haveing to
reinstall all kernel related packages, and unable to keep already
installed versions) - I am sure someone must have had a bug against that
one.

BillK

On Sun, 2003-10-05 at 02:27, Patrick Börjesson wrote:
> > In theory, Portage could track them if ebuild could be modified to use
> > /usr/src/pkg when it existed instead of /var/tmp/portage/*/work and
> > the application was installed via 'ebuild pkg merge'. I'm not sure how
> > possible that would be for implementation, though.
> 
> But then the question is: Why? We already have the source unpacked in
> /var/tmp/portage/*/work so why "move" it to /usr/src? There are already
> ways for people to do the configure- and make-steps them selves if they



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Patrick Börjesson]

[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]

> because a number of other packages want to see /usr/src/linux for the
> running kernel.  lm-sensors, vmware, nvidia, ...

I was referring to the ordinary packages (not the kernels) when talking
about moving the unpacked source from /var/tmp/portage/*/work to
/usr/src. As it's almost always necessary for user-interaction when
configuring the kernel it's needed for the source of the kernel to
remain in /usr/src and not be removed as soon as emerge is finished
doing it's thing. But the ordinary packages' source-code can be safely
removed after the merge (if you don't want to do something special to
the source in case you would use the ebuild-command instead). I thought
it was pretty clear what I meant in my previous post...

> I do agree that some effort should be put into fixing the unwanted
> effects that occur when you install another kernel though (haveing to
> reinstall all kernel related packages, and unable to keep already
> installed versions) - I am sure someone must have had a bug against
> that one.

I'm sure alot of people do =) As am I.

> On Sun, 2003-10-05 at 02:27, Patrick Börjesson wrote:
> > > In theory, Portage could track them if ebuild could be modified to
> > > use/usr/src/pkg when it existed instead of /var/tmp/portage/*/work
> > > and the application was installed via 'ebuild pkg merge'. I'm not
> > > sure how possible that would be for implementation, though.
> > 
> > But then the question is: Why? We already have the source unpacked
> > in/var/tmp/portage/*/work so why "move" it to /usr/src? There are
> > already ways for people to do the configure- and make-steps them
> > selves if they

Patrick Börjesson

-- 
Public key id: 4C5AB0BF
Public key available at search.keyserver.net[:11371]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[William Kenworthy]

Unfortunately, this seems to be the "standard" way to do this. Once you
build and install a new kernel, you must rebuild all the existing deps
such as the above - ok thats fine, but my beef is that emerge uninstalls
the modules built into the old kernel when it builds for the new one,
leaving the old kernel crippled unless you remember to manually protect
the modules.

this something truly useful that genkernel could address.

Reading my previous email, it appears I imply that genkernel is of
little use.  Quite the opposite, as well as new users, it has some good
uses on first install to set up unfamiliar hardware.  Once running, you
can analyse it (lsmod etc) and set up a tuned manual configuration. 
Hence why I am persevering with it.

BillK

On Sun, 2003-10-05 at 08:43, Sami Näätänen wrote:
> On Sunday 05 October 2003 02:38, William Kenworthy wrote:
> > because a number of other packages want to see /usr/src/linux for the
> > running kernel.  lm-sensors, vmware, nvidia, ...
> 

> In my opinion those packages shouldn't use /usr/src/linux, but to let 
> the user decide the kernel, which the package should be build against.
> 



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 04 October 2003 06:27 pm, Patrick Börjesson wrote:
> But then the question is: Why? We already have the source unpacked in
> /var/tmp/portage/*/work so why "move" it to /usr/src?
One could say the same for /var/tmp/portage/*/image... Why put it there and 
move it to /?

> There are already
> ways for people to do the configure- and make-steps them selves if they
> wish (through the ebuild-command as you yourself said). As I see it
> there would be no advantage reimplementing it the proposed way...
Nothing in /var/tmp should be expected to continue to exist any longer than 
the process which created them is running. They usually do, but they should 
not be expected to.

> As for the kernels to be auto-configured, why not do it the same way as
> some other packages do it: have an extra section in the ebuild that
> configures the kernel for you through genkernel... Several other
> packages already have this section (think it's called config) including
> postresql. This could be advertised in the same way as in the
> postresql-ebuild at the end of the emerge-command, and thus everybody
> has a choice in how they would like to configure and compile the kernel.
As it is right now, there is no choice. Implementation of the idea would add 
an option, and emerging linux-src would do the same as emerging 
vanilla-sources does right now.
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/f4SIZl/BHdU+lYMRArUWAKCXlnTslyPKdDHjLOU4HO5vT1FQWgCfcVc+
ak6Hmex5PfH3sY2HWrW0UoI=
=32zv
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Stroller]

On 4 Oct 2003, at 1:40 pm, Stuart Herbert wrote:

> On Saturday 04 October 2003 5:29 am, Jason Stubbs wrote:
>> A lot of work would need to be done to do this successfully, though; 
>> maybe
>> something that should be left for portage v3...
>>
>> Jason
>
> Just because I'm emerged any particular set of kernel sources does 
> *not* mean
> that a) I want that kernel adding to lilo/grub yet, and b) that my box 
> has
> everything else in place to boot and run that kernel.
>
> It's not broken, so please don't try to fix it.

Seconded.

Genkernel did not work for me the one & only time I tried it. The 
kernel panicked on boot-up, and I had to wait an hour & a half longer 
whilst I recompiled it by hand. I copied .config from the old linux 
directory, `make menuconfig`d, saved & exited, `make dep && make clean 
bzImage modules modules_install, just like I always did (without even 
knowing what the `make dep` does, even) and the new kernel worked 
perfectly.

I am sure I am doing a huge injustice to the author of genkernel, but 
it's more hassle for me to find out what I did wrong than to continue 
to do things manually.

Please can we keep things simple..? Gentoo is such a great 
distribution, complexity has the potential to diminish it from its 
current (IMO) near perfection. Surely there are far better things for 
inclusion in Portage3. Iis there any timeframe on that, BTW..?

Stroller.



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[William Kenworthy]

And failed on 2 goes for me, two different installs for me so far. 
First one I cant remember, but the one yesterday hung soon after failing
to reallocate root filesystem (or similar)

Deleted some thing I shouldnt have soon after, so am now reinstalling
and will have another go.

Also not really sold on the idea of auto detecting everything on bootup
for a working system.  Seems slow to boot (as far as it went) and has a
lot of cruft attached (unused modules, kernel options etc).  If you go
the menuconfig route, you may as well do it all by hand, and remove the
possiblity of initrd problems.

Also, does compiling in the LiveCD gui window (blue) seem much-much
slower than a normal tty to others?  Took 36hours to do bootstrap on a
K6-500, but emerge system seems quite fast now I switched to a normal
console.

BillK

On Sat, 2003-10-04 at 21:33, Stroller wrote:
> On 4 Oct 2003, at 1:40 pm, Stuart Herbert wrote:
> 
> > On Saturday 04 October 2003 5:29 am, Jason Stubbs wrote:
> >> A lot of work would need to be done to do this successfully, though; 

> 
> Seconded.
> 
> Genkernel did not work for me the one & only time I tried it. The 



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 04 October 2003 02:08 pm, William Kenworthy wrote:
> And failed on 2 goes for me, two different installs for me so far.
> First one I cant remember, but the one yesterday hung soon after failing
> to reallocate root filesystem (or similar)
I believe I had a problem similar to this a while ago. Turned out there was an 
undocumented env variable that needed to be set before genkernel was run... 
Not sure if the same issue still exists tho.
>
> Also not really sold on the idea of auto detecting everything on bootup
> for a working system.  Seems slow to boot (as far as it went) and has a
> lot of cruft attached (unused modules, kernel options etc).  If you go
> the menuconfig route, you may as well do it all by hand, and remove the
> possiblity of initrd problems.
But many users want to be able to simply change hardware and have it work 
automaticly. Sure, you could probably preset your configuration and gain a 
bit of speed, but then you could need to change something if you want to 
change your hardware. Either way, there's a sacrifice. That's why there's an 
option. :)
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/ftd5Zl/BHdU+lYMRAlQjAJ4rPyy2DcvNFMG2phYpLfWtHnAbRgCgmxGr
PcQBYbJCE3zIwhgELy1yWCk=
=Sdxa
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 04 October 2003 01:33 pm, Stroller wrote:
> Please can we keep things simple..? Gentoo is such a great
> distribution, complexity has the potential to diminish it from its
> current (IMO) near perfection. Surely there are far better things for
> inclusion in Portage3. Iis there any timeframe on that, BTW..?
We already recommend using genkernel in the manual for 1.4, so moving this 
into an ebuild wouldn't be very different from how it is now. Personally, I 
am satisfied with how the kernels are done right now, but I brought it up 
because it sounds like a feature that could be useful on some systems or by 
some people and it would fit more in with the current Portage setup where 
everything is automaticly compiled. Though I would like to see the -src 
suffix get in at some point even if the kernels stay the same. I keep /var/
tmp/portage, but sometimes it might be nice to have the sources in /usr/src 
too. I don't think Portage3 would be neccesary for this... It could probably 
be a few well placed lines in the current Portage to add it, though I suppose 
I would say the same for sticky USE flags. Can a Portage dev comment on how 
complex/simple it would be to implement -src?
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/ftXRZl/BHdU+lYMRAv9oAJ99Z52pq+O8ydq1YCTnE6kLVu9J6gCfX208
XDTxmDFfoBlBpNrN9yFn6uQ=
=a+lg
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Peter Ruskin]

On Saturday 04 Oct 2003 14:33, Stroller wrote:
> I am sure I am doing a huge injustice to the author of genkernel, but
> it's more hassle for me to find out what I did wrong than to continue
> to do things manually.
>
> Please can we keep things simple..? Gentoo is such a great
> distribution, complexity has the potential to diminish it from its
> current (IMO) near perfection. Surely there are far better things for
> inclusion in Portage3. Iis there any timeframe on that, BTW..?

I agree.  I also tried genkernel once and took an instant dislike to it.

I'd prefer it if more effort were put into the ability to switch kernels 
without having always to remerge nvidia, lm+sensors and the like cf. 
http://bugs.gentoo.org/show_bug.cgi?id=1477

Peter
-- 
======================================================================
Portage 2.0.49-r3 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1, 
2.4.22_pre2-gss)
i686 AMD Athlon(tm) XP 3200+
======================================================================


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Patrick Börjesson]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

> The day that Gentoo *forces* me to use a kernel auto-magically
> configured and compiled for me through an 'emerge' is the day that
> Gentoo joins my RedHat CDs in the bin.
> 
> Just because I'm emerged any particular set of kernel sources does
> *not* mean that a) I want that kernel adding to lilo/grub yet, and b)
> that my box has everything else in place to boot and run that kernel.
> 
> It's not broken, so please don't try to fix it.
> 
> Why can't this just be left alone?!?

I totally agree!

I've always thought of genkernel as a tool for those not "competent"
enough to compile the kernel by them selves... As such I don't think it
should be something that is used by default but rather something that
gets mentioned in the install-docs, and not forced on users.

Patrick Börjesson

-- 
Public key id: 4C5AB0BF
Public key available at search.keyserver.net[:11371]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 04 October 2003 01:50 pm, Patrick Börjesson wrote:
> I've always thought of genkernel as a tool for those not "competent"
> enough to compile the kernel by them selves... As such I don't think it
> should be something that is used by default but rather something that
> gets mentioned in the install-docs, and not forced on users.
Compiling the kernel is quite simple: 'make bzImage modules'
I believe you mean configuring, which genkernel still lets you do.
Also, as I said, there could be a -src suffix to install the source. For 
example, what about people who would consider themselves "competent" enough 
to compile GCC or KDE themselves? =p
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/ftHbZl/BHdU+lYMRAplEAKCMJ8n5G2rK3HvkQnodYc8ypXVXMACbBGoP
M49o5V9d1U/eMsvPSaZY/kI=
=AG9f
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Jon Portnoy]

On Sat, Oct 04, 2003 at 01:57:42PM +0000, Luke-Jr wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Saturday 04 October 2003 01:50 pm, Patrick Börjesson wrote:
> > I've always thought of genkernel as a tool for those not "competent"
> > enough to compile the kernel by them selves... As such I don't think it
> > should be something that is used by default but rather something that
> > gets mentioned in the install-docs, and not forced on users.
> Compiling the kernel is quite simple: 'make bzImage modules'
> I believe you mean configuring, which genkernel still lets you do.
> Also, as I said, there could be a -src suffix to install the source. For 
> example, what about people who would consider themselves "competent" enough 
> to compile GCC or KDE themselves? =p

Every dev and user who has responded has said it's a Very Bad Idea. Why 
are you still arguing for it?


-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 04 October 2003 04:13 pm, Jon Portnoy wrote:
> Every dev and user who has responded has said it's a Very Bad Idea. Why
> are you still arguing for it?
I am still *discussing* it because there have been things to respond to. IIRC, 
most of which have been misunderstanding the idea. I don't expect many people 
on -dev would use such a feature anyway, it would mostly be used by people 
not involved in development very much who might use it.
Again, it was just an idea and I don't care much whether or not it gets 
implemented, but that's no reason to ignore the idea completely and not 
discuss various positive or negative impacts it would have.
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/fwJ/Zl/BHdU+lYMRAr12AJ91WvLnEUX56uo30tClnXGYeqpEmwCfT3Oq
hu8JaP0vKP1IUxtztDigtw0=
=ZgQZ
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Jason Stubbs]

On Sunday 05 October 2003 01:13, Jon Portnoy wrote:
> On Sat, Oct 04, 2003 at 01:57:42PM +0000, Luke-Jr wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Saturday 04 October 2003 01:50 pm, Patrick Börjesson wrote:
> > > I've always thought of genkernel as a tool for those not "competent"
> > > enough to compile the kernel by them selves... As such I don't think it
> > > should be something that is used by default but rather something that
> > > gets mentioned in the install-docs, and not forced on users.
> >
> > Compiling the kernel is quite simple: 'make bzImage modules'
> > I believe you mean configuring, which genkernel still lets you do.
> > Also, as I said, there could be a -src suffix to install the source. For
> > example, what about people who would consider themselves "competent"
> > enough to compile GCC or KDE themselves? =p
>
> Every dev and user who has responded has said it's a Very Bad Idea. Why
> are you still arguing for it?

Ahem?

I think the main point to the discussion is new users. I, too, have never used 
genkernel so don't know how viable the idea of using it in its current state 
would be. Nor am I admonishing that it should be the "only way to go". 
However, everything in Gentoo is configured, compiled and installed through 
the single emerge command. It would make most sense to me to choose what 
classes of drivers/functionality I wanted through USE flags and then do 
post-installation configuration through /etc/modules.autoload*. Can anyone 
say why the kernel is special and should be done differently? - other than if 
it ain't broke don't fix it! 

I'm with almost all other people in that it would not be a high priority for 
some time to come. On the other hand, I'm against people who are putting 
forward arguments that the kernel is somehow special. Almost every other 
package is installed with extra cruft so that can't be used as an excuse. 
Gentoo is about making things easier for everyone which means safe defaults 
and easily accessible complete customisation, so Luke-Jr's idea at least 
deserves consideration rather than instant dismissal.

Jason

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Kumba]

Jason Stubbs wrote:

> Ahem?
> 
> I think the main point to the discussion is new users. I, too, have never used 
> genkernel so don't know how viable the idea of using it in its current state 
> would be. Nor am I admonishing that it should be the "only way to go". 
> However, everything in Gentoo is configured, compiled and installed through 
> the single emerge command. It would make most sense to me to choose what 
> classes of drivers/functionality I wanted through USE flags and then do 
> post-installation configuration through /etc/modules.autoload*. Can anyone 
> say why the kernel is special and should be done differently? - other than if 
> it ain't broke don't fix it! 

> I'm with almost all other people in that it would not be a high priority for 
> some time to come. On the other hand, I'm against people who are putting 
> forward arguments that the kernel is somehow special. Almost every other 
> package is installed with extra cruft so that can't be used as an excuse. 
> Gentoo is about making things easier for everyone which means safe defaults 
> and easily accessible complete customisation, so Luke-Jr's idea at least 
> deserves consideration rather than instant dismissal.
> 
> Jason

Honestly, the kernel is special.  Everyone has a different x86 
machine...different NIC card, sound card, video card, motherboard, IDE 
chipset, scsi card, CPU....Some have V4L, some have I2C stuff, some have 
parallel ports, some have ISA, some have PCI, some have both, some have 
serial console, some have radeons, some have nvidias.....See the point?

x86 is *way* too diverse an architecture to configure solely through USE 
Flags.  How can it be set so we know whether someone has a VIA IDE 
chipset and not an SiS, or how someone have a RealTek 8139-based NIC 
card, and whether they need the old RealTek driver, or the newer one?

As much as we all love Gentoo for it's ability to configure things 
easily (in most cases), the kernel to me is just that one little nuance 
that stands apart from the base system.  Everyone should learn how to 
configure their kernel, in my opinion.  It is probably the one thing 
every linux distro should teach people how to do.  The advantages far 
outweigh the disadvantages, and by building their own kernel, the user 
becomes aware of what is inside their machine.

genkernel is a great idea, and kudos to the original author.  But 
genkernel is aimed at being a temporary solution to help a user get 
their system up and running quickly.  Then they'll eventually sit down 
and configure their own kernel.  Right now, genkernel is just an option. 
  Users don't have to use it if they don't want to, and this should stay 
that way as it fits with Gentoo's philosophy of providing user's with 
choices.  I'd also like to see genkernel modified to handle other 
architectures too -- this would give it a boost with other distros that 
support multiple archs.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[James Harlow]

On Sat, Oct 04, 2003 at 08:17:11PM -0400, Kumba wrote:
> x86 is *way* too diverse an architecture to configure solely through USE 
> Flags. 

Well, this isn't true, it wouldn't take more than a couple hundred. Of
course, this would be pretty difficult to sift through by hand, and they
can depend on each other in interesting ways, so someone would probably
need to write some sort of tool to set them and feed this back to the
kernel - maybe more than one tool - one ncurses-based, one pure text,
one qt, or maybe something wacky like tcltk. We could call these tools
something like "menuflagconfig", "xflagconfig", "flagconfig", or 
something similar. Actually, I'm surprised no-one has already done 
anything  like this.

-- 
When a true genius appears in the world, you may know him by this sign, that the dunces are all in confederacy against him. - Jonathan Swift

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Jason Stubbs]

On Sunday 05 October 2003 09:25, James Harlow wrote:
> On Sat, Oct 04, 2003 at 08:17:11PM -0400, Kumba wrote:
> > x86 is *way* too diverse an architecture to configure solely through USE
> > Flags.
>
> Well, this isn't true, it wouldn't take more than a couple hundred. Of
> course, this would be pretty difficult to sift through by hand, and they
> can depend on each other in interesting ways, so someone would probably
> need to write some sort of tool to set them and feed this back to the
> kernel - maybe more than one tool - one ncurses-based, one pure text,
> one qt, or maybe something wacky like tcltk. We could call these tools
> something like "menuflagconfig", "xflagconfig", "flagconfig", or
> something similar. Actually, I'm surprised no-one has already done
> anything  like this.

Sarcasm never helps anything in serious discussion...

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[James Harlow]

On Sun, Oct 05, 2003 at 09:38:21AM +0900, Jason Stubbs wrote:
> Sarcasm never helps anything in serious discussion...

Ah, ok, then I apologise. I was only being semi-sarcastic, though,
because it seems to me that the CONFIG_ options are pretty much
equivalent to use flags.

-- 
When a true genius appears in the world, you may know him by this sign, that the dunces are all in confederacy against him. - Jonathan Swift

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Kumba]

Jason Stubbs wrote:

> Sarcasm never helps anything in serious discussion...

Sarcasm is rather useful, although, bizarre statements have much more 
effect.  Bizarre statements such as asking "So, did anyone hear that 
Kermit the Frog just got signed to the Redskins for 8 years @ 252 
million as their new quarterback?".  These tend to make people look at 
you oddly, thus breaking the tension that can sometimes occur in a 
serious discussion...

(That or they'll just ignore you and write you off as a total looney.)


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Jason Stubbs]

On Sunday 05 October 2003 11:10, Kumba wrote:
> Jason Stubbs wrote:
> > Sarcasm never helps anything in serious discussion...
>
> Sarcasm is rather useful, although, bizarre statements have much more
> effect.  Bizarre statements such as asking "So, did anyone hear that
> Kermit the Frog just got signed to the Redskins for 8 years @ 252
> million as their new quarterback?".  These tend to make people look at
> you oddly, thus breaking the tension that can sometimes occur in a
> serious discussion...

I agree with you there, _but_ sarcasm directed at the 'opposition' can only be 
taken as a personal attack. Actually, I use sarcasm all the time in a serious 
discussion, but it is always directed at myself. Anyways...

Jason

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Kumba]

James Harlow wrote:

[snip]
> Well, this isn't true, it wouldn't take more than a couple hundred. Of
> course, this would be pretty difficult to sift through by hand...
[snip]

A couple hundred?  I think that alone justifies my statetment that x86 
is far too diverse to configure via USE Flags.  We already have 176 
global useflags (line count in /usr/portage/profiles/use.desc) and 187 
local useflags (line count in /usr/portage/profiles/use.local.desc). 
All these useflags are spread across the ~5000 packages in Portage. 
Adding another "couple hundred" specifically for x86 kernels alone is 
overkill to the point of using C4 explosive to clear out a yellow jacket 
nest in the ground.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Jason Stubbs]

On Sunday 05 October 2003 11:06, Kumba wrote:
> James Harlow wrote:
> > Well, this isn't true, it wouldn't take more than a couple hundred. Of
> > course, this would be pretty difficult to sift through by hand...
>
> A couple hundred?  I think that alone justifies my statetment that x86
> is far too diverse to configure via USE Flags.  We already have 176
> global useflags (line count in /usr/portage/profiles/use.desc) and 187
> local useflags (line count in /usr/portage/profiles/use.local.desc).
> All these useflags are spread across the ~5000 packages in Portage.
> Adding another "couple hundred" specifically for x86 kernels alone is
> overkill to the point of using C4 explosive to clear out a yellow jacket
> nest in the ground.

Did you read my other post? The idea of adding a use flag for every single 
device is ridiculous. I'm just talking about use flags for classes of 
hardware. Looking at use.desc, there are already 27 flags related to hardware 
and 18 flags related to interfaces to that hardware. Here's a list.

hardware: 3dfx, 3dnow, acpi, alpha, apm, arm, cdr, dvb, dvd, dvdr, fbcon, 
joystick, matrox, mips, mmx, nocardbus, pcmcia, pda, pnp, ppc, scanner, 
sparc, sse, usb, voodoo3, wavelan, x86

interfaces: alsa, arts, dga, directfb, esd, ggi, gphoto2, gpm, jack, ladcca, 
opengl, oss, ppds, sdl, svga, xinerama, xosd, xv

What I'm suggesting (and don't really care if it's implemented) is that the 
above are combined into common "super" classes and other classes added.

Jason

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Jon Portnoy]

On Sun, Oct 05, 2003 at 01:25:09AM +0100, James Harlow wrote:
> On Sat, Oct 04, 2003 at 08:17:11PM -0400, Kumba wrote:
> > x86 is *way* too diverse an architecture to configure solely through USE 
> > Flags. 
> 
> Well, this isn't true, it wouldn't take more than a couple hundred. Of
> course, this would be pretty difficult to sift through by hand, and they
> can depend on each other in interesting ways, so someone would probably
> need to write some sort of tool to set them and feed this back to the
> kernel - maybe more than one tool - one ncurses-based, one pure text,
> one qt, or maybe something wacky like tcltk. We could call these tools
> something like "menuflagconfig", "xflagconfig", "flagconfig", or 
> something similar. Actually, I'm surprised no-one has already done 
> anything  like this.
> 

They have. It's called "make *config"

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Kevyn Shortell]

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

On Sat, 2003-10-04 at 17:25, James Harlow wrote:

> Well, this isn't true, it wouldn't take more than a couple hundred. Of
> course, this would be pretty difficult to sift through by hand, and they
> can depend on each other in interesting ways, so someone would probably
> need to write some sort of tool to set them and feed this back to the
> kernel - maybe more than one tool - one ncurses-based, one pure text,
> one qt, or maybe something wacky like tcltk. We could call these tools
> something like "menuflagconfig", "xflagconfig", "flagconfig", or 
> something similar. Actually, I'm surprised no-one has already done 
> anything  like this.

And this couple of hundred use flags, a user is supposed to know those
all how? Suddenly, I see your proposal being more of a pain in the butt
than the "problem".

So what your suggesting is to take something most people can figure out
in a day or two, by reading the help, or a web page and making it more
complex? Why on earth do you think this is a better solution?

The reason why no one has done this before is, you don't fix something
that isn't broken. Linux kernel compiles were never intented for new
users. Gentoo has changed that, and has a basic tool to help users out,
but Gentoo doesn't claim to be a distro for new users to linux.

Trance

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Jason Stubbs]

On Sunday 05 October 2003 09:17, Kumba wrote:
> Jason Stubbs wrote:
> > It would make most sense to
> > me to choose what classes of drivers/functionality I wanted through USE
> > flags and then do post-installation configuration through
> > /etc/modules.autoload*. Can anyone say why the kernel is special and
> > should be done differently? - other than if it ain't broke don't fix it!
>
> Honestly, the kernel is special.  Everyone has a different x86
> machine...different NIC card, sound card, video card, motherboard, IDE
> chipset, scsi card, CPU....Some have V4L, some have I2C stuff, some have
> parallel ports, some have ISA, some have PCI, some have both, some have
> serial console, some have radeons, some have nvidias.....See the point?

What I was thinking with the USE flag idea was that "audio", for example, 
would build all of the audio drivers, etc. Similar to what "emerge xfree" 
does.

> x86 is *way* too diverse an architecture to configure solely through USE
> Flags.  How can it be set so we know whether someone has a VIA IDE
> chipset and not an SiS, or how someone have a RealTek 8139-based NIC
> card, and whether they need the old RealTek driver, or the newer one?

Hmmm... it is safe to build in drivers for several chipsets, if not a little 
bloated. The old/new realtek driver couldn't be handled, however. But that's 
why it would be imperative to have a source extraction option to mimic what 
is presently done.

> As much as we all love Gentoo for it's ability to configure things 
> easily (in most cases), the kernel to me is just that one little nuance 
> that stands apart from the base system. Everyone should learn how to 
> configure their kernel, in my opinion. It is probably the one thing 
> every linux distro should teach people how to do. The advantages far 
> outweigh the disadvantages, and by building their own kernel, the user 
> becomes aware of what is inside their machine.

I agree that all users should really know how to build a kernel. But I also 
think that every user should know how to download a source tarball and 
compile and install it manually. Knowledge is power...

All in all,  I'm happy with the way things are done now. I'm just a firm 
believer in standards.

Jason

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 05 October 2003 12:17 am, Kumba wrote:
> x86 is *way* too diverse an architecture to configure solely through USE
> Flags.  How can it be set so we know whether someone has a VIA IDE
> chipset and not an SiS, or how someone have a RealTek 8139-based NIC
> card, and whether they need the old RealTek driver, or the newer one?
Last I checked, these configs could be changed after it is compiled. If it is 
impossible to do, then how is it that RedHat and all the binary distros have 
a single kernel for x86?
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/f4VvZl/BHdU+lYMRAs93AJ9hEiNVrUQtiSMki8oMA83SPcy/GwCeLr5R
V7F/3UkDh/OJa/Yaex2QaKU=
=7CvU
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Kumba]

Luke-Jr wrote:

> Last I checked, these configs could be changed after it is compiled. If it is 
> impossible to do, then how is it that RedHat and all the binary distros have 
> a single kernel for x86?

-mcpu=i[3456]86 -march=i[3456]86 + modules madness


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 05 October 2003 03:04 am, Kumba wrote:
> Luke-Jr wrote:
> > Last I checked, these configs could be changed after it is compiled. If
> > it is impossible to do, then how is it that RedHat and all the binary
> > distros have a single kernel for x86?
>
> -mcpu=i[3456]86 -march=i[3456]86 + modules madness
Isn't the CFLAGS variable in make.conf meant for -mcpu and -march? genkernel 
already takes care of modules.
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/gCmlZl/BHdU+lYMRAiDIAJ9H4oo//y+kCSlpa6IDKEB15EhaUgCfe2vS
4u3sJOHR2L16nqLNDzEZHGI=
=vf9S
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Kevyn Shortell]

[-- Attachment #1: Type: text/plain, Size: 2364 bytes --]


> 
> I think the main point to the discussion is new users. I, too, have never used 
> genkernel so don't know how viable the idea of using it in its current state 
> would be. Nor am I admonishing that it should be the "only way to go". 
> However, everything in Gentoo is configured, compiled and installed through 
> the single emerge command. It would make most sense to me to choose what 
> classes of drivers/functionality I wanted through USE flags and then do 
> post-installation configuration through /etc/modules.autoload*. Can anyone 
> say why the kernel is special and should be done differently? - other than if 
> it ain't broke don't fix it! 

Because the kernel is much more than that. Linux as a whole has never
setup kernel building for new users, and probably never will. You
actually need to know a lot about your hardware to build an optimized
kernel for it. 

To put into basic perspective, if you want to have USE flags for kernel
building, would you know to use something like:

USE="pnp network pci radeon 16550 tulip ohci ps2 ipv4 ext3 idecd ata100
dma 

The list goes on and on. There are somethings as a user your going to
just have to decide to learn how to do. If not you can always use the rh
sources, and thier config to have a kernel that will boot almost
anything. Using use flags as you suggested, still requires you to know a
lot about your hardware, which wouldn't help you from using the current
kernel configuration system, which is not gentoo specific.
> 
> I'm with almost all other people in that it would not be a high priority for 
> some time to come. On the other hand, I'm against people who are putting 
> forward arguments that the kernel is somehow special. Almost every other 
> package is installed with extra cruft so that can't be used as an excuse. 
> Gentoo is about making things easier for everyone which means safe defaults 
> and easily accessible complete customisation, so Luke-Jr's idea at least 
> deserves consideration rather than instant dismissal.

I don't think anyone has an argument with making things easier, but we
shouldn't make things easier for new users to the detriment of making
things more difficult for everyone else. There is a point where Gentoo
just might be more advanced than a new user is skill wise, and accept
that. 

trance


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Jason Stubbs]

On Sunday 05 October 2003 14:22, Kevyn Shortell wrote:
> > I think the main point to the discussion is new users. I, too, have never
> > used genkernel so don't know how viable the idea of using it in its
> > current state would be. Nor am I admonishing that it should be the "only
> > way to go". However, everything in Gentoo is configured, compiled and
> > installed through the single emerge command. It would make most sense to
> > me to choose what classes of drivers/functionality I wanted through USE
> > flags and then do post-installation configuration through
> > /etc/modules.autoload*. Can anyone say why the kernel is special and
> > should be done differently? - other than if it ain't broke don't fix it!
>
> Because the kernel is much more than that. Linux as a whole has never
> setup kernel building for new users, and probably never will. You
> actually need to know a lot about your hardware to build an optimized
> kernel for it.

I'm not talking about a fully-optimized kernel. I'm talking about for the "new 
user" who is competent enough to reach building a kernel but is at a loss 
once reaching that point in an installation.

> To put into basic perspective, if you want to have USE flags for kernel
> building, would you know to use something like:
>
> USE="pnp network pci radeon 16550 tulip ohci ps2 ipv4 ext3 idecd ata100
> dma
>
> The list goes on and on. There are somethings as a user your going to
> just have to decide to learn how to do. If not you can always use the rh
> sources, and thier config to have a kernel that will boot almost
> anything. Using use flags as you suggested, still requires you to know a
> lot about your hardware, which wouldn't help you from using the current
> kernel configuration system, which is not gentoo specific.

To take your example, I would prefer something like:

USE="network 3daccel usb cdrom"

Comparing to your example, what I'm suggesting as a simple possibility is:
"network" = "network" + "tulip" + "ipv4"
"3daccel" = "radeon" (+ "i810", etc)
"usb" = "ohci" (+ "uhci" + "ehci", etc)
"cdrom" = "idecd" (+ "idescsi", etc)

"comm", "ps2", "usb", "pnp", "pci", "ext3" & "ata100" would all be installed 
by default as they don't add any negatives other than a small amount of 
memory usage or wasted time attempting to load modules.

A while a go there was one email to -user asking what he was doing wrong when 
genkernel was taking several hours. The simple reason was that it was 
compiling almost everything. I'm simply offering a solution where it is easy 
for a user to be pretty sure a compiled kernel will operate all his/her 
hardware (as far as the kernel is capable) without spending time building all 
drivers for some class of device that isn't in the system.

> > I'm with almost all other people in that it would not be a high priority
> > for some time to come. On the other hand, I'm against people who are
> > putting forward arguments that the kernel is somehow special. Almost
> > every other package is installed with extra cruft so that can't be used
> > as an excuse. Gentoo is about making things easier for everyone which
> > means safe defaults and easily accessible complete customisation, so
> > Luke-Jr's idea at least deserves consideration rather than instant
> > dismissal.
>
> I don't think anyone has an argument with making things easier, but we
> shouldn't make things easier for new users to the detriment of making
> things more difficult for everyone else. There is a point where Gentoo
> just might be more advanced than a new user is skill wise, and accept
> that.

Nobody's talking about making things harder for everyone else. "emerge 
linux-gentoo-src" as Luke-Jr suggested is detrimentally difficult when 
compared to "emerge gentoo-sources" is it? 2 extra keystrokes?! There are 
also many people saying that Gentoo might just be too hard for lusers. Why 
then was genkernel created in the first place?

Jason

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Jason Stubbs]

On Sunday 05 October 2003 23:41, Sami Näätänen wrote:
> On Sunday 05 October 2003 14:30, Jason Stubbs wrote:
> > On Sunday 05 October 2003 14:22, Kevyn Shortell wrote:
> > > I don't think anyone has an argument with making things easier, but
> > > we shouldn't make things easier for new users to the detriment of
> > > making things more difficult for everyone else. There is a point
> > > where Gentoo just might be more advanced than a new user is skill
> > > wise, and accept that.
> >
> > Nobody's talking about making things harder for everyone else.
> > "emerge linux-gentoo-src" as Luke-Jr suggested is detrimentally
> > difficult when compared to "emerge gentoo-sources" is it? 2 extra
> > keystrokes?! There are also many people saying that Gentoo might just
> > be too hard for lusers. Why then was genkernel created in the first
> > place?
>
> I'm certainly in favor of making the -src thing to active, because it
> really gives people the full power. For example I have some times
> wanted to look the code used in a package. I of course can simply untar
> the tarball somewhere, but if the package contains multiple tarballs I
> either has to find them, or start to ebuild package.ebuild unpack stuff
> and then move the source tree from the temp location to somewhere where
> it is not going to be overwriten. I although don't suggest that -src
> suffix, but an option to the emerge, which tells it to install this
> software to package's SLOT="$P-src", from which I then could be looking
> in $PORT_SRC_DIR/$P-src.

Agreed here. An option to emerge is much more intuitive.

> Oh and the kernel packages that would compile the kernel should install
> the kernel headers of the compiled kernel to
> /usr/src/linux-`uname -r`/include/
> so that any package that needs the real kernel headers can find them.

Er, I'm pretty sure that the packages that need the source in /usr/src/linux 
need more than just the headers - but don't quote me on that!

Regards,
Jason

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 05 October 2003 02:47 pm, Jason Stubbs wrote:
> > I although don't suggest that -src
> > suffix, but an option to the emerge, which tells it to install this
> > software to package's SLOT="$P-src", from which I then could be looking
> > in $PORT_SRC_DIR/$P-src.
> Agreed here. An option to emerge is much more intuitive.
However, it prevents packages from DEPENDing on it. For example, if the 
kernels were to ever use the genkernel thing, nvidia-kernel might DEPEND on 
nvidia-kernel if it actually needed the source for it. I also don't think it 
should automaticly provide the package it is the source for until the user 
uses ebuild to install/merge it into the system.
>
> > Oh and the kernel packages that would compile the kernel should install
> > the kernel headers of the compiled kernel to
> > /usr/src/linux-`uname -r`/include/
> > so that any package that needs the real kernel headers can find them.
> Er, I'm pretty sure that the packages that need the source in
> /usr/src/linux need more than just the headers - but don't quote me on
> that!
I can't think of any valid reason they would need to do so, but I've never 
done much of anything with the kernel.
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/gD6ZZl/BHdU+lYMRAo+mAJ48Zu/YNRmBBbiLQm4ou6L+2MiBGQCeL2uq
xNvWJzLh5tDwbA+utGXtwGY=
=4Ilp
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 05 October 2003 03:53 pm, Luke-Jr wrote:
> kernels were to ever use the genkernel thing, nvidia-kernel might DEPEND on
> nvidia-kernel if it actually needed the source for it. I also don't think
...might DEPEND on linux-src... (oops)
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/gEFeZl/BHdU+lYMRAoMIAJ9dQF6BG4edD4DecMaypjrCltlJNwCgjG3p
GIaJWqP+KRDRRKLGtP4ee2w=
=EaCa
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 04 October 2003 04:29 am, Jason Stubbs wrote:
> However, having portage compile and install Linux has several issues.
> Portage would need  to be able to:
> 1) handle multiple saved configurations automatically.
Perhaps there could be a KERNEL_CONFIG option which looks for a different 
config file for genkernel w/ KERNEL_CONFIG appended and then appends 
KERNEL_CONFIG to the output kernel. SLOTting this could allow one to install 
it multiple times with different KERNEL_CONFIG.

> 2) update lilo/grub automatically _with_ backup.
I don't think it's the backups that would be complex to do, but the updating 
of lilo/grub automaticly. Does it really need to be done, though? The ebuilds 
could theoreticly manage a set of symlinks /boot/{kernel,initrd}{,-
{current,previous}} (also a {kernel,initrd}-working which is set after a user 
successfully logs in?) and let the user determine whether to use them or to 
manually manage their kernel config.

> 3) extract the source to /usr/src if need be (as already mentioned)
> 4) handle different configurations of the same kernel version.
>
> Tangible benefits that I can see:
> 1) ccache can be used in compiling the kernel automatically
I don't see that ccache is all that great. I'd much rather Portage leave the 
original /var/tmp/portage/*/work directories when remerging a package so they 
can reuse the object files that are still consistant.

> 2) a lot of disk space can be saved.
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/fsXAZl/BHdU+lYMRAkO0AJ43/WiVjCwX8qvFwjTaaFcHd7kjugCglWCz
RIZAXPj6dXTvAm2S83yw2lg=
=/RpY
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

On Fri, 2003-10-03 at 23:56, Luke-Jr wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Saturday 04 October 2003 02:25 am, Jon Portnoy wrote:
> > You're not suggesting anything that provides a tangible benefit, you're
> > just suggesting expanding our tree to do something we already do. That
> > doesn't make sense.
> 
> As it is currently done, Portage cannot track the kernel itself, only the 
> kernel sources. Also, it leaves the kernel in /usr/src/linux when it isn't 
> really needed once installed except perhaps to save configuration (which 
> genkernel has stuff for) and object files to speed future compilations (which 
> Portage should do if you keep /var/tmp/portage around anyway).
> It makes little sense to compile and install other packages but not compile 
> and install Linux itself.
> - -- 

And all the kernel module ebuilds.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Kumba]

Luke-Jr wrote:

> Another suggestion... Why not move away from -sources and make ebuilds based 
> on genkernel (eg. sys-kernel/{,{gentoo,redhat,suse,...}-}linux). There would 
> need to be something for manual configuration changes, but I believe 
> genkernel already supports something like this. The only problem I can see is 
> that it would end up recompiling the entire kernel for every configuration 
> change, though that's a Portage bug that affects all ebuilds currently.
> Is there any reason to install the kernel sources anymore and not do this?

I'm quite fine installing kernel sources.  There is still a random 
package or three out there that expects to have a valid /usr/src/linux 
link.  Also, genkernel is not a good idea, IMHO, mainly because it is 
x86-specific.  It does not take into account the non-x86 kernel sources 
we maintain.

How difficult it would be to modify genkernel to be arch independent, I 
have no idea.  It probably wouldn't take much, but would require input 
from all arch teams to explain the various behaviors between kernels. 
sparc/sparc64 for instance does not use a "bzImage" target, but instead 
a "vmlinux" target on 2.4.  vmlinux is dropped off in the root of the 
kernel tree.  In 2.6, sparc/sparc64 use "make Image", and drops a file 
off in arch/sparc[64]/boot.  ppc, hppa, & mips are probably different in 
some aspects.

All in all, I guess I'm  a bit of a purist...I kinda like having a 
kernel tree around, and with the advent of huge harddrives, the ~200mb 
of space it takes up is almost negligible.

Besides, it's fun to have a copy of the kernel source lying around to 
grep for funny C comments when you're bored.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Kevyn Shortell]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

On Fri, 2003-10-03 at 16:50, Luke-Jr wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Another suggestion... Why not move away from -sources and make ebuilds based 
> on genkernel (eg. sys-kernel/{,{gentoo,redhat,suse,...}-}linux). There would 
> need to be something for manual configuration changes, but I believe 
> genkernel already supports something like this. The only problem I can see is 
> that it would end up recompiling the entire kernel for every configuration 
> change, though that's a Portage bug that affects all ebuilds currently.
> Is there any reason to install the kernel sources anymore and not do this?
> - -- 
> Luke-Jr
> Developer, Gentoo Linux

I've pretty much kept quiet about this, but I'd like to take this moment
to remind people, that Gentoo, is not just x86, the kernel team is not
just people who build x86 kernels, and Gentoo tools to build kernels,
should be required to run on all arches before Gentoo decides to make
them a standard method during install for users.

trance



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 04 October 2003 07:27 am, Kevyn Shortell wrote:
> I've pretty much kept quiet about this, but I'd like to take this moment
> to remind people, that Gentoo, is not just x86, the kernel team is not
> just people who build x86 kernels, and Gentoo tools to build kernels,
> should be required to run on all arches before Gentoo decides to make
> them a standard method during install for users.

I'd actually been assuming all this would work with non-x86 platforms. Worst 
case, though, unsupported platforms could use the linux-src feature of my 
suggestion. I think it'd be better if genkernel could gain support for other 
arch tho.
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/fshKZl/BHdU+lYMRApbuAJ4nlVu4ByjGzi4cMZ5h1/WN1yE4BQCfQOFG
WIMEV/Rlp/P34u/sXCA9gJ0=
=zZOo
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Stroller]

On 3 Oct 2003, at 4:34 pm, Brian Jackson wrote:
> There will probably be a few -sources removed. But the decision of 
> what is not
> made yet.

I was clearly under a misapprehension here. I rather assumed that 
Gentoo-sources were the only ones maintained by the Gentoo -dev team. I 
rather assumed that in the case of vanilla-sources & all the others 
`emerge some-sources` simply downloaded a complete set of kernel 
sources from some repository & then unzipped them.

Could someone please clarify what I'm failing to understand..?
Are wolk-, redhat-, secure-, mm- & ck-sources not distributed as 
complete tarballs..?

Stroller.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Donnie Berkholz]

On Fri, 2003-10-03 at 22:03, Stroller wrote:
> On 3 Oct 2003, at 4:34 pm, Brian Jackson wrote:
> > There will probably be a few -sources removed. But the decision of 
> > what is not
> > made yet.
> 
> I was clearly under a misapprehension here. I rather assumed that 
> Gentoo-sources were the only ones maintained by the Gentoo -dev team. I 
> rather assumed that in the case of vanilla-sources & all the others 
> `emerge some-sources` simply downloaded a complete set of kernel 
> sources from some repository & then unzipped them.
> 
> Could someone please clarify what I'm failing to understand..?
> Are wolk-, redhat-, secure-, mm- & ck-sources not distributed as 
> complete tarballs..?

In many cases, it's a vanilla kernel and a prepackaged patchset.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Stroller]

On 4 Oct 2003, at 3:08 am, Donnie Berkholz wrote:

>> Could someone please clarify what I'm failing to understand..?
>> Are wolk-, redhat-, secure-, mm- & ck-sources not distributed as
>> complete tarballs..?
>
> In many cases, it's a vanilla kernel and a prepackaged patchset.

Right. So those should (theoretically) require zero maintenance from 
Gentoo -devs, then..? Apart from an eBuild wrapper.

Stroller.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Speaking of new kernels being added to the tree

[Sami Näätänen]

On Sunday 05 October 2003 18:53, Luke-Jr wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sunday 05 October 2003 02:47 pm, Jason Stubbs wrote:
> > > I although don't suggest that -src
> > > suffix, but an option to the emerge, which tells it to install
> > > this software to package's SLOT="$P-src", from which I then could
> > > be looking in $PORT_SRC_DIR/$P-src.
> >
> > Agreed here. An option to emerge is much more intuitive.
>
> However, it prevents packages from DEPENDing on it. For example, if
> the kernels were to ever use the genkernel thing, nvidia-kernel might
> DEPEND on nvidia-kernel if it actually needed the source for it. I
> also don't think it should automaticly provide the package it is the
> source for until the user uses ebuild to install/merge it into the
> system.

Those modules can only be compiled to kernels that already has a
dependecy information made. So in older kernels this means make dep and
never kernels needs the config process done. After this point the
kernel include dir, which these packages need can be used.

The guestion is how would we manage the finding of the kernel include
dir for the source installed version. As I proposed the env variable
could be used if the user want's to build the package for different
kernel than the currently running kernel.

This would be good in other perspective too. Say we install new kernel
linux-2.6.0-test18 through this new version of portage. So it would
compile and install the kernel it's modules and the include tree. After
this portage could compile the module packages present in system to
this new kernel and add the module files to the module dir and to the
packages CONTENT file, so that all of the made modules would be removed
in a case where the corresponding package is removed from the system.
So Portage could set this kernel source variable to correct location
before compiling the module packages.

The variable should be kernel_includes or something, because that's
 what the packages need not the full source tree.
As an example the NVidia kernel module needs quite many header files to
determine the correct sizes of many kernel type definitions. And some
configuration information like was the kernel compiled with SMP support
or not. This all can be retrived from the kernel include dir and it's
sub directories.

> > > Oh and the kernel packages that would compile the kernel should
> > > install the kernel headers of the compiled kernel to
> > > /usr/src/linux-`uname -r`/include/
> > > so that any package that needs the real kernel headers can find
> > > them.
> >
> > Er, I'm pretty sure that the packages that need the source in
> > /usr/src/linux need more than just the headers - but don't quote me
> > on that!
>
> I can't think of any valid reason they would need to do so, but I've
> never done much of anything with the kernel.

Well that kind of perversive package will borke very fast.
And besides only thing I can think of that would need the kernel source
location is patch to kernel, but those should be delt before the kernel
installation not after.



--
gentoo-dev@gentoo.org mailing list