First extending yum's exclude setting with packages excluded from the compose in the kickstart package manifest helps in group selection (see also #456882), since @core has a mandatory package called "fedora-logos". Although livecd-tools already removes the packages (after package and group selection) in the excluded list, I think this is cleaner as not even dependency resolving will know about the package explicitly excluded (and the package is thus not pulled in accidently, afterwards).
Kind regards,
Jeroen van Meeuwen -kanarip
On Mon, 2008-07-28 at 22:44 +0200, Jeroen van Meeuwen wrote:
First extending yum's exclude setting with packages excluded from the compose in the kickstart package manifest helps in group selection (see also #456882), since @core has a mandatory package called "fedora-logos". Although livecd-tools already removes the packages (after package and group selection) in the excluded list, I think this is cleaner as not even dependency resolving will know about the package explicitly excluded (and the package is thus not pulled in accidently, afterwards).
The problem with this is that it's an (albeit subtle) change in what the semantics of the kickstart config are. The fact that you don't end up with broken deps, even if you do something silly like -glibc, is something that's been relatively important in the past. And given that you can do per-repo exclusion of packages, I don't know that switching to - being an exclude vs a deselect is advantageous enough to outweigh the loss wrt broken deps.
Especially as any change here needs to be handled consistently across all tools using kickstart files, not just livecd-creator.
Jeremy
Jeremy Katz wrote:
On Mon, 2008-07-28 at 22:44 +0200, Jeroen van Meeuwen wrote:
First extending yum's exclude setting with packages excluded from the compose in the kickstart package manifest helps in group selection (see also #456882), since @core has a mandatory package called "fedora-logos". Although livecd-tools already removes the packages (after package and group selection) in the excluded list, I think this is cleaner as not even dependency resolving will know about the package explicitly excluded (and the package is thus not pulled in accidently, afterwards).
The problem with this is that it's an (albeit subtle) change in what the semantics of the kickstart config are. The fact that you don't end up with broken deps, even if you do something silly like -glibc, is something that's been relatively important in the past. And given that you can do per-repo exclusion of packages,
This sounds to me like moving the exclude functionality of the package manifest to the repo configuration directive...
I don't know that switching
to - being an exclude vs a deselect is advantageous enough to outweigh the loss wrt broken deps.
If you do something like -glibc you may have very good reasons for doing so. Note that -glibc and including customly-compiled-appliance-worthy-glibc is a very, very valid use case.
1) an explicit exclude should be excluded no matter what. Failed dependencies are a good indicator you have excluded the wrong package.
2) Randomly including what is explicitly indicated should be excluded changes the semantics of the kickstart package manifest from "a decent way to configure what packages should be on the system, and what packages should absolutely not" to a "monkey's selection of the available packages". If you can't reasonably, accurately predict what it does, it's done for.
Especially as any change here needs to be handled consistently across all tools using kickstart files, not just livecd-creator.
Well... actually only the tools using kickstart files that have exclusive dependency resolving. pungi for example has inclusive dependency resolving and ignores the explicit package manifest excludes as well, and for valid reasons as it is allowing conflicts in the package set because it's installation media and doesn't know what packages may or may not be preferred. Revisor then again allows exclusive dependency resolving as well and again is one of the tools on the list that is going to change (for the better, as I explained).
You give me a list of packages or tools that show this kind of behavour, please. I know anaconda is one of them, so what else?
Kind regards,
Jeroen van Meeuwen -kanarip
On Wed, 2008-07-30 at 10:53 +0200, Jeroen van Meeuwen wrote:
Jeremy Katz wrote:
On Mon, 2008-07-28 at 22:44 +0200, Jeroen van Meeuwen wrote:
First extending yum's exclude setting with packages excluded from the compose in the kickstart package manifest helps in group selection (see also #456882), since @core has a mandatory package called "fedora-logos". Although livecd-tools already removes the packages (after package and group selection) in the excluded list, I think this is cleaner as not even dependency resolving will know about the package explicitly excluded (and the package is thus not pulled in accidently, afterwards).
The problem with this is that it's an (albeit subtle) change in what the semantics of the kickstart config are. The fact that you don't end up with broken deps, even if you do something silly like -glibc, is something that's been relatively important in the past. And given that you can do per-repo exclusion of packages,
This sounds to me like moving the exclude functionality of the package manifest to the repo configuration directive...
I don't know that switching
to - being an exclude vs a deselect is advantageous enough to outweigh the loss wrt broken deps.
If you do something like -glibc you may have very good reasons for doing so. Note that -glibc and including customly-compiled-appliance-worthy-glibc is a very, very valid use case.
And if you have %packages -glibc customly-compiled-appliance-worthy-glibc
in your ks.cfg, then you'll get you the customly compiled one as long as it satisfies all the deps. If it _doesn't_, then yes, you might get glibc pulled in
- an explicit exclude should be excluded no matter what. Failed
dependencies are a good indicator you have excluded the wrong package.
Failed dependencies can indicate lots of things, depending on the context. And not all tools (anaconda being a notable case, pungi being another afaik) will happily let you intsall/build trees with broken deps, going for exclusion rather than deselection can lead to a seriously hosed system
- Randomly including what is explicitly indicated should be excluded
changes the semantics of the kickstart package manifest from "a decent way to configure what packages should be on the system, and what packages should absolutely not" to a "monkey's selection of the available packages". If you can't reasonably, accurately predict what it does, it's done for.
People have been using kickstart in this fashion for a long, long, long time without it being "done for". But I appreciate the hyperbole.
Especially as any change here needs to be handled consistently across all tools using kickstart files, not just livecd-creator.
Well... actually only the tools using kickstart files that have exclusive dependency resolving. pungi for example has inclusive dependency resolving and ignores the explicit package manifest excludes as well, and for valid reasons as it is allowing conflicts in the package set because it's installation media and doesn't know what packages may or may not be preferred. Revisor then again allows exclusive dependency resolving as well and again is one of the tools on the list that is going to change (for the better, as I explained).
You give me a list of packages or tools that show this kind of behavour, please. I know anaconda is one of them, so what else?
anaconda, pungi, livecd-creator, snake... that's off the top of my head. But the bigger thing to change is people's *perception*. If you're used to one thing, changing those semantics is very dangerous and it's something that we've been very very very careful to avoid doing with the kickstart file format. To the point of introducing entirely new syntax in cases where there could be confusion.
Hence, why I say it's not clear to me why you wouldn't in this case just do excludes at the repo level since that provides the same level of functionality but without any of the fuzziness around changing the semantics of the existing syntax
Jeremy
On Thu July 31 2008 11:06:18 Jeroen van Meeuwen wrote:
Jeremy,
my final answer is on planet.fp.o right now.
Interesting ...
Read the archive thread 'pilgrim livecd work' 20/09/2006 06:51 and in particular the post by your community manager Greg DeKoenigsberg for were you stand with anaconda. GOOD LUCK
...dex
livecd@lists.fedoraproject.org
-
dexter -
Jeremy Katz -
Jeroen van Meeuwen