| Summary: | cascading profiles: default-linux packages file includes a kernel | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Pieter Van den Abeele (RETIRED) <pvdabeel> |
| Component: | [OLD] Core system | Assignee: | Seemant Kulleen (RETIRED) <seemant> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | zhen |
| Priority: | High | ||
| Version: | 2004.1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Pieter Van den Abeele (RETIRED)
2004-03-31 05:08:07 UTC
seemant handles the cascading profiles, forwarding to him well, the way I understood it, is that packages.build is what catalyst uses. The premise behind cascading profiles is that it is a high-level definition of what comprises a basic linux system (in this case). In order for a linux system to be "linux" and run at all is a kernel, which is why virtual/linux-sources is part of the base system. I think you can probably create a packages.build file in your profile and do -virtual/linux-sources in there to solve your stage3 My opinion is that it would be cleanest to remove the kernel from the stage3 profile, because we don't include a kernel with the stage3. A kernel might be needed inside the stage3 while it is building, but the catalyst tool should take care of that. the profiles don't care between stage1, stage2, or stage3 they care only about a running system -- what is important/crucial to have on a running system? a kernel qualifies. if catalyst is building a kernel for inclusion into a stage 3, that's not a profiles issue, it's a catalyst issue. The whole point of the system profile is to define what packages need to be emerged when migrating from stage2 to stage3. Gentoo kernel ebuilds only install the kernel sources and not the kernel binary. I have seen numerous systems that run and don't have kernel sources installed. The livecd for instance hasn't got kernel sources installed, but runs without a problem. We also don't include a bootloader in the 'emerge system' profile even though this is a package needed to have a running system. My concern is that if a kernel or a bootloader is added to the emerge system profile (marked with a *), this will lead to the following: People starting from stage1 or stage2 that run emerge system will have a kernel installed they may not like. Just for clarity: this bug is about the 'packages' file of the default-linux profile, not the 'packages.build'. 'packages.build' defines what packages need to be merged to build a stage1 (order in which these packages are emerged is important and hardcoded in the file.) 'packages' defines various constraints on the system. Lines with a '*' are must have. These are emerged during 'emerge system' in a stage2. It is possible to pinpoint a specific version of a package. Some examples: *=glibc-2.3.2 means you need to have glibc-2.3.2 installed =glibc-2.3.2 means that if glibc is installed, it needs to be version 2.3.2 if you add *>beep-1.2 then a version of beep larger than 1.2 will be installed during emerge system. It is also possible to mask things by using: ~beep which means that beep cannot be installed. (This is how we used to mask packages when keywords didn't exist yet). fixed Thnxs. Saved the mirrors a few megs: -rw-r--r-- 1 root root 100653905 Apr 4 20:58 stage3-ppc-20040404.tar.bz2 (regular 2004.0) -rw-r--r-- 1 root root 130303402 Apr 9 03:45 stage3-ppc-20040409.tar.bz2 (cascading 2004.0) |