No patch attached because it's quite large. I apologize for the length, but considering this replaces a library and introduces a new struct it meant a new file and changing calls everywhere.
http://dcantrel.fedorapeople.org/anaconda/iface/
iface.h - Header file explaining the iface API. iface_t structure replacing pumpNetIntf and networkDeviceConfig, and all of the functions. iface.patch - The changes, it's about 90% complete at this point. *.txt - Explanations and notes.
This patch removes anaconda's use of libdhcp, which also means removing libdhcp4client and libdhcp6client. For static network configuration, I am using libnl. To gather current network interface information, I am using libnl. To control IPv6 autoconf, I read/ write /proc since that's all we can do right now. For DHCP and DHCPv6, I run dhclient and dhcp6c, respectively.
I'd like everyone to have a look at iface.h and the patch file. It's not complete yet, so I probably know about the obvious things (the FIXMEs and the useless debugging printfs and the incomplete isys.py code and so on). The goal with iface.patch is to get us closer to using NetworkManager in stage 1 and stage 2. I envision the NM changeover to be just as large, but hopefully by then we will have decided to nuke certain parts of loader entirely. Completely eliminating libdhcp and friends will be a nice step.
There are some other things that need discussion as well. mkinitrd currently uses libdhcp, for example. This had me thinking we could generate libisys in an anaconda-devel package for things like mkinitrd, but I'm just brainstorming. Maybe I should put the iface code elsewhere? I dunno. At any rate, mkinitrd needs to be not left out.
Work in progress, comments welcome.
David Cantrell wrote:
No patch attached because it's quite large. I apologize for the length, but considering this replaces a library and introduces a new struct it meant a new file and changing calls everywhere.
http://dcantrel.fedorapeople.org/anaconda/iface/iface.h - Header file explaining the iface API. iface_t structure replacing pumpNetIntf and networkDeviceConfig, and all of the functions. iface.patch - The changes, it's about 90% complete at this point. *.txt - Explanations and notes.
This patch removes anaconda's use of libdhcp,
Why? How will your patch improve Anaconda?[1] How is/will Network Manager be better? Does the result use less RAM?
I'm sure there are more questions.
[1] I accept that reducing duplicated code is good.
On May 21, 2008, at 2:01 AM, John Summerfield wrote:
David Cantrell wrote:
No patch attached because it's quite large. I apologize for the length, but considering this replaces a library and introduces a new struct it meant a new file and changing calls everywhere. http://dcantrel.fedorapeople.org/anaconda/iface/ iface.h - Header file explaining the iface API. iface_t structure replacing pumpNetIntf and networkDeviceConfig, and all of the functions. iface.patch - The changes, it's about 90% complete at this point. *.txt - Explanations and notes. This patch removes anaconda's use of libdhcp,
Why? How will your patch improve Anaconda?[1]
libdhcp replaced libpump around F-5 or so. It's been nothing but trouble since then as it just wraps the client daemons and provides a sloppy control system around talking to them. And the dhcp clients don't even get executed correctly via this library anyway. It's been a real pain to keep working and it just needs to go.
So, the patch has us directly configuring interfaces using libnl (which is used by NM), and running the actual client daemons for dhcp and dhcpv6 when the user requests configuration that way. The same way it run on the target system.
How is/will Network Manager be better?
It's what the final system uses by default now and it's what we [the installer team/distribution] would like to ultimately use for network interface configuration during installation. If it's good enough for the final system, it should be good enough for the installer. So, it's more about using the same code for the same tasks.
Does the result use less RAM?
Not necessarily. But maybe.
David Cantrell wrote:
On May 21, 2008, at 2:01 AM, John Summerfield wrote:
David Cantrell wrote:
No patch attached because it's quite large. I apologize for the length, but considering this replaces a library and introduces a new struct it meant a new file and changing calls everywhere. http://dcantrel.fedorapeople.org/anaconda/iface/ iface.h - Header file explaining the iface API. iface_t structure replacing pumpNetIntf and networkDeviceConfig, and all of the functions. iface.patch - The changes, it's about 90% complete at this point. *.txt - Explanations and notes. This patch removes anaconda's use of libdhcp,
Why? How will your patch improve Anaconda?[1]
libdhcp replaced libpump around F-5 or so. It's been nothing but
What was wrong with libpump?
trouble since then as it just wraps the client daemons and provides a sloppy control system around talking to them. And the dhcp clients don't even get executed correctly via this library anyway. It's been a real pain to keep working and it just needs to go.
So, the patch has us directly configuring interfaces using libnl (which is used by NM), and running the actual client daemons for dhcp and dhcpv6 when the user requests configuration that way. The same way it run on the target system.
How is/will Network Manager be better?
It's what the final system uses by default now and it's what we [the installer team/distribution] would like to ultimately use for network interface configuration during installation. If it's good enough for the final system, it should be good enough for the installer. So, it's more about using the same code for the same tasks.
Well, nm has (or should have, it was a bit limited when I last fought it) much more functionality than the installer's likely to need.
Does the result use less RAM?
Not necessarily. But maybe.
Bear in mind that one of the major critcisms of Anaconda is its ever-expanding size. Folk were pretty unhappy with it arount RHL7 when some folk were trying to create an alternative, for smaller systems. Back then, I recall, one could install with 64 Mbytes of RAM.
More recently _I_ was pretty unhappy when it took over 12 hours to upgrade, in 256 Mbytes, from FC3 to FC5.
I favour a simple dhcp client that does an adequate job over a complex, over-featured alternative.
libdhcp replaced libpump around F-5 or so. It's been nothing but
What was wrong with libpump?
The initial motivation for replacing libpump with libdhcp was that libpump had no support for IPv6 and that support was a requirement for RHEL5.
Well, nm has (or should have, it was a bit limited when I last fought it) much more functionality than the installer's likely to need.
For now, true. However the biggest advantage here is that it's the same code the rest of the system uses. That means we inherit all the same bugs and all the same bug fixes. We've had too much of our own duplicate code that's only used by anaconda for too long.
Bear in mind that one of the major critcisms of Anaconda is its ever-expanding size. Folk were pretty unhappy with it arount RHL7 when some folk were trying to create an alternative, for smaller systems. Back then, I recall, one could install with 64 Mbytes of RAM.
More recently _I_ was pretty unhappy when it took over 12 hours to upgrade, in 256 Mbytes, from FC3 to FC5.
I favour a simple dhcp client that does an adequate job over a complex, over-featured alternative.
On the other hand, our requirements (especially from enterprise customers) are increasing as well. Networking and storage are two areas in particular where we are seeing more and more unusual requests. We can either continue to write our own code to handle these things or use what the rest of the system is using and not have to worry about becoming experts at every single new thing.
- Chris
Chris Lumens (clumens@redhat.com) said:
libdhcp replaced libpump around F-5 or so. It's been nothing but
What was wrong with libpump?
The initial motivation for replacing libpump with libdhcp was that libpump had no support for IPv6 and that support was a requirement for RHEL5.
... and that it was an entirely separate codebase for DHCP which means that the installer would have different success and failure characteristics than the rebooted system.
Bill
Bill Nottingham wrote:
Chris Lumens (clumens@redhat.com) said:
libdhcp replaced libpump around F-5 or so. It's been nothing but
What was wrong with libpump?
The initial motivation for replacing libpump with libdhcp was that libpump had no support for IPv6 and that support was a requirement for RHEL5.
... and that it was an entirely separate codebase for DHCP which means that the installer would have different success and failure characteristics than the rebooted system.
For my journey to work, an electric bicycle is close to ideal, it's not very far and I mostly don't carry much.
However, my wife needs a car, she carries more and public transport's not a realistic option.
Whatever the installed system's requirements might be (and it's the mobility of my laptop that brought nm down), I'd have thought Anaconda's requirements to be fairly basic, more akin to the bicycle than the car.
I do think keeping Anaconda's overall size (RAM usage) down is important.
On Tue, 2008-05-20 at 18:40 -1000, David Cantrell wrote:
No patch attached because it's quite large. I apologize for the length, but considering this replaces a library and introduces a new struct it meant a new file and changing calls everywhere.
I know it's large and I know that splitting up patches is a pain, but it really does increase the ability to review them which then ends up having a positive impact on the end result. And there's a fair bit of just renaming variables, etc in there. Which could be looked at on their own, easily validated and then overall shrinking the real meat of the patch.
The biggest concrete thing I was able to see trying to churn through the patch is that /sbin/dhclient-script depends on bash which we don't have in the first stage at this point.
This patch removes anaconda's use of libdhcp, which also means removing libdhcp4client and libdhcp6client. For static network configuration, I am using libnl. To gather current network interface information, I am using libnl. To control IPv6 autoconf, I read/ write /proc since that's all we can do right now. For DHCP and DHCPv6, I run dhclient and dhcp6c, respectively.
I'd like everyone to have a look at iface.h and the patch file. It's not complete yet, so I probably know about the obvious things (the FIXMEs and the useless debugging printfs and the incomplete isys.py code and so on). The goal with iface.patch is to get us closer to using NetworkManager in stage 1 and stage 2. I envision the NM changeover to be just as large, but hopefully by then we will have decided to nuke certain parts of loader entirely. Completely eliminating libdhcp and friends will be a nice step.
So, I'm going to ask the obvious question which ends up staring us in the face at this point. Why not use NetworkManager like the rest of the OS *now* instead of making another wheel for ourselves that in all likelihood, will end up having to be maintained for on the order of years.
The biggest reason I can come up with after thinking about it all night is that we'd end up pulling in more junk to the initrd (hal and dbus at the very least) and I wasn't entirely thrilled about doing that just for hardware detection. But maybe it really is the right thing to do now. The other downside is that we'd probably still need to have our own control code to prompt for information and then send that to NetworkManager. And yeah, substantial change. But meh, so was the udev/hal stuff
The positive benefit would be that we'd largely be out of this business and could reassign the bugs ;) Plus, it'd make it easier for us to decide to start supporting things like installs over wireless using WPA.
There are some other things that need discussion as well. mkinitrd currently uses libdhcp, for example. This had me thinking we could generate libisys in an anaconda-devel package for things like mkinitrd, but I'm just brainstorming. Maybe I should put the iface code elsewhere? I dunno. At any rate, mkinitrd needs to be not left out.
A libisys seems like a bad idea as isys is best summed up as a set of bodges around things the OS doesn't sanely provide for us ;) And I don't even want to think about trying to maintain any sort of API or ABI compatibility for it.
The right fix for mkinitrd given the direction we continue to move in there is probably to switch away from nash builtins and just suck in the appropriate utilities into the initrd. But that's not an easy move either.
Jeremy
On Wed, May 21, 2008 at 09:35:30AM -0400, Jeremy Katz wrote:
On Tue, 2008-05-20 at 18:40 -1000, David Cantrell wrote:
This patch removes anaconda's use of libdhcp, which also means removing libdhcp4client and libdhcp6client. For static network configuration, I am using libnl. To gather current network interface information, I am using libnl. To control IPv6 autoconf, I read/ write /proc since that's all we can do right now. For DHCP and DHCPv6, I run dhclient and dhcp6c, respectively.
I'd like everyone to have a look at iface.h and the patch file. It's not complete yet, so I probably know about the obvious things (the FIXMEs and the useless debugging printfs and the incomplete isys.py code and so on). The goal with iface.patch is to get us closer to using NetworkManager in stage 1 and stage 2. I envision the NM changeover to be just as large, but hopefully by then we will have decided to nuke certain parts of loader entirely. Completely eliminating libdhcp and friends will be a nice step.
So, I'm going to ask the obvious question which ends up staring us in the face at this point. Why not use NetworkManager like the rest of the OS *now* instead of making another wheel for ourselves that in all likelihood, will end up having to be maintained for on the order of years.
What about distros that don't use NetworkManager? Will there be a fall back? If we are using NetworkManager with Anaconda will it still able able to generate "classic" network configuration?
Elliot
On May 21, 2008, at 5:50 AM, Elliot Peele wrote:
On Wed, May 21, 2008 at 09:35:30AM -0400, Jeremy Katz wrote:
On Tue, 2008-05-20 at 18:40 -1000, David Cantrell wrote:
This patch removes anaconda's use of libdhcp, which also means removing libdhcp4client and libdhcp6client. For static network configuration, I am using libnl. To gather current network interface information, I am using libnl. To control IPv6 autoconf, I read/ write /proc since that's all we can do right now. For DHCP and DHCPv6, I run dhclient and dhcp6c, respectively.
I'd like everyone to have a look at iface.h and the patch file. It's not complete yet, so I probably know about the obvious things (the FIXMEs and the useless debugging printfs and the incomplete isys.py code and so on). The goal with iface.patch is to get us closer to using NetworkManager in stage 1 and stage 2. I envision the NM changeover to be just as large, but hopefully by then we will have decided to nuke certain parts of loader entirely. Completely eliminating libdhcp and friends will be a nice step.
So, I'm going to ask the obvious question which ends up staring us in the face at this point. Why not use NetworkManager like the rest of the OS *now* instead of making another wheel for ourselves that in all likelihood, will end up having to be maintained for on the order of years.
What about distros that don't use NetworkManager? Will there be a fall back? If we are using NetworkManager with Anaconda will it still able able to generate "classic" network configuration?
Personally, I'd rather not allow users the option to create a classic set of ifcfg-* files if we are doing NM by default. As long as it's an option, people will still use it, which means we'll still have to support multiple ways of configuring network devices on the target system. If we're going NM for everything, it should be NM for everything.
On Wed, 2008-05-21 at 07:48 -1000, David Cantrell wrote:
On May 21, 2008, at 5:50 AM, Elliot Peele wrote:
What about distros that don't use NetworkManager? Will there be a fall back? If we are using NetworkManager with Anaconda will it still able able to generate "classic" network configuration?
Personally, I'd rather not allow users the option to create a classic set of ifcfg-* files if we are doing NM by default. As long as it's an option, people will still use it, which means we'll still have to support multiple ways of configuring network devices on the target system. If we're going NM for everything, it should be NM for everything.
Generating ifcfg-* files is still sane with NetworkManager, though. It uses them for the system-settings backend
Jeremy
On May 21, 2008, at 8:08 AM, Jeremy Katz wrote:
On Wed, 2008-05-21 at 07:48 -1000, David Cantrell wrote:
On May 21, 2008, at 5:50 AM, Elliot Peele wrote:
What about distros that don't use NetworkManager? Will there be a fall back? If we are using NetworkManager with Anaconda will it still able able to generate "classic" network configuration?
Personally, I'd rather not allow users the option to create a classic set of ifcfg-* files if we are doing NM by default. As long as it's an option, people will still use it, which means we'll still have to support multiple ways of configuring network devices on the target system. If we're going NM for everything, it should be NM for everything.
Generating ifcfg-* files is still sane with NetworkManager, though. It uses them for the system-settings backend
Right, but don't we need to write NM_CONTROLLED=i_think_so| probably_not to the ifcfg-* if the user wants "classic" config style or not? And that would either need to be a switch somewhere (UI, boot arg, serial port dongle, kickstart flag, special spin of Fedora, etc), right?
On Wed, 2008-05-21 at 08:13 -1000, David Cantrell wrote:
On May 21, 2008, at 8:08 AM, Jeremy Katz wrote:
Generating ifcfg-* files is still sane with NetworkManager, though. It uses them for the system-settings backend
Right, but don't we need to write NM_CONTROLLED=i_think_so| probably_not to the ifcfg-* if the user wants "classic" config style or not? And that would either need to be a switch somewhere (UI, boot arg, serial port dongle, kickstart flag, special spin of Fedora, etc), right?
The default if NetworkManager is around is that NM_CONTROLLED is assumed to be 1 if not present in the file, iirc
Jeremy
On May 21, 2008, at 8:12 AM, Jeremy Katz wrote:
On Wed, 2008-05-21 at 08:13 -1000, David Cantrell wrote:
On May 21, 2008, at 8:08 AM, Jeremy Katz wrote:
Generating ifcfg-* files is still sane with NetworkManager, though. It uses them for the system-settings backend
Right, but don't we need to write NM_CONTROLLED=i_think_so| probably_not to the ifcfg-* if the user wants "classic" config style or not? And that would either need to be a switch somewhere (UI, boot arg, serial port dongle, kickstart flag, special spin of Fedora, etc), right?
The default if NetworkManager is around is that NM_CONTROLLED is assumed to be 1 if not present in the file, iirc
Oh right, durh....of course it wouldn't matter what the NM_CONTROLLED value is if it's not even on the system.
I got up at 6:30 AM today, give me a break.
On Wed, 2008-05-21 at 11:50 -0400, Elliot Peele wrote:
On Wed, May 21, 2008 at 09:35:30AM -0400, Jeremy Katz wrote:
On Tue, 2008-05-20 at 18:40 -1000, David Cantrell wrote:
This patch removes anaconda's use of libdhcp, which also means removing libdhcp4client and libdhcp6client. For static network configuration, I am using libnl. To gather current network interface information, I am using libnl. To control IPv6 autoconf, I read/ write /proc since that's all we can do right now. For DHCP and DHCPv6, I run dhclient and dhcp6c, respectively.
I'd like everyone to have a look at iface.h and the patch file. It's not complete yet, so I probably know about the obvious things (the FIXMEs and the useless debugging printfs and the incomplete isys.py code and so on). The goal with iface.patch is to get us closer to using NetworkManager in stage 1 and stage 2. I envision the NM changeover to be just as large, but hopefully by then we will have decided to nuke certain parts of loader entirely. Completely eliminating libdhcp and friends will be a nice step.
So, I'm going to ask the obvious question which ends up staring us in the face at this point. Why not use NetworkManager like the rest of the OS *now* instead of making another wheel for ourselves that in all likelihood, will end up having to be maintained for on the order of years.
What about distros that don't use NetworkManager? Will there be a fall back? If we are using NetworkManager with Anaconda will it still able able to generate "classic" network configuration?
Honestly, I think that's getting more to the point of "what about distros that don't use udev/hal" or something along those lines. A more constructive thing would be to figure out how NetworkManager doesn't fit your use cases and try to get those resolved.
But writing out ifcfg-* files is probably still something that will remain in some form or fashion, but from a UI perspective, interactive installs may not want to expose a lot of it.
Jeremy
On May 21, 2008, at 3:35 AM, Jeremy Katz wrote:
On Tue, 2008-05-20 at 18:40 -1000, David Cantrell wrote:
No patch attached because it's quite large. I apologize for the length, but considering this replaces a library and introduces a new struct it meant a new file and changing calls everywhere.
I know it's large and I know that splitting up patches is a pain, but it really does increase the ability to review them which then ends up having a positive impact on the end result. And there's a fair bit of just renaming variables, etc in there. Which could be looked at on their own, easily validated and then overall shrinking the real meat of the patch.
I can use splitdiff and create three patches or so.
The biggest concrete thing I was able to see trying to churn through the patch is that /sbin/dhclient-script depends on bash which we don't have in the first stage at this point.
The patch should include a line to patch mk-images that brings bash in.
This patch removes anaconda's use of libdhcp, which also means removing libdhcp4client and libdhcp6client. For static network configuration, I am using libnl. To gather current network interface information, I am using libnl. To control IPv6 autoconf, I read/ write /proc since that's all we can do right now. For DHCP and DHCPv6, I run dhclient and dhcp6c, respectively.
I'd like everyone to have a look at iface.h and the patch file. It's not complete yet, so I probably know about the obvious things (the FIXMEs and the useless debugging printfs and the incomplete isys.py code and so on). The goal with iface.patch is to get us closer to using NetworkManager in stage 1 and stage 2. I envision the NM changeover to be just as large, but hopefully by then we will have decided to nuke certain parts of loader entirely. Completely eliminating libdhcp and friends will be a nice step.
So, I'm going to ask the obvious question which ends up staring us in the face at this point. Why not use NetworkManager like the rest of the OS *now* instead of making another wheel for ourselves that in all likelihood, will end up having to be maintained for on the order of years.
The biggest reason I can come up with after thinking about it all night is that we'd end up pulling in more junk to the initrd (hal and dbus at the very least) and I wasn't entirely thrilled about doing that just for hardware detection. But maybe it really is the right thing to do now. The other downside is that we'd probably still need to have our own control code to prompt for information and then send that to NetworkManager. And yeah, substantial change. But meh, so was the udev/hal stuff
The positive benefit would be that we'd largely be out of this business and could reassign the bugs ;) Plus, it'd make it easier for us to decide to start supporting things like installs over wireless using WPA.
The driving goal for me has been "get rid of libdhcp fast". So I put this patch together hoping I could merge it in to rawhide sooner rather than later and then have some time to work up a move-to-NM patch. If people want to skip that interim step entirely, I'm cool with that and can go ahead and start moving it to NM entirely. Not knowing how long that would take, I just focused on removing libdhcp for now and leaving our current functionality in place.
There are some other things that need discussion as well. mkinitrd currently uses libdhcp, for example. This had me thinking we could generate libisys in an anaconda-devel package for things like mkinitrd, but I'm just brainstorming. Maybe I should put the iface code elsewhere? I dunno. At any rate, mkinitrd needs to be not left out.
A libisys seems like a bad idea as isys is best summed up as a set of bodges around things the OS doesn't sanely provide for us ;) And I don't even want to think about trying to maintain any sort of API or ABI compatibility for it.
Agreed, was just throwing out an idea for mkinitrd since something will need to happen with it once libdhcp goes away.
The right fix for mkinitrd given the direction we continue to move in there is probably to switch away from nash builtins and just suck in the appropriate utilities into the initrd. But that's not an easy move either.
That's an entire project by itself, I think.
On Wed, 2008-05-21 at 07:43 -1000, David Cantrell wrote:
The driving goal for me has been "get rid of libdhcp fast". So I put this patch together hoping I could merge it in to rawhide sooner rather than later and then have some time to work up a move-to-NM patch. If people want to skip that interim step entirely, I'm cool with that and can go ahead and start moving it to NM entirely. Not knowing how long that would take, I just focused on removing libdhcp for now and leaving our current functionality in place.
Fair enough... I just think that we might as well get the real end goal in place, even if it takes a little bit longer. It will end up saving effort overall as we won't have to fix things in the interim step.
[snip]
The right fix for mkinitrd given the direction we continue to move in there is probably to switch away from nash builtins and just suck in the appropriate utilities into the initrd. But that's not an easy move either.
That's an entire project by itself, I think.
Yep. Hence, I wouldn't try and tie it at all to this set of changes. Which might mean that libdhcp sticks around for a minor case for a little bit longer, but hopefully not that much longer.
Jeremy
On May 21, 2008, at 8:10 AM, Jeremy Katz wrote:
On Wed, 2008-05-21 at 07:43 -1000, David Cantrell wrote:
The driving goal for me has been "get rid of libdhcp fast". So I put this patch together hoping I could merge it in to rawhide sooner rather than later and then have some time to work up a move-to-NM patch. If people want to skip that interim step entirely, I'm cool with that and can go ahead and start moving it to NM entirely. Not knowing how long that would take, I just focused on removing libdhcp for now and leaving our current functionality in place.
Fair enough... I just think that we might as well get the real end goal in place, even if it takes a little bit longer. It will end up saving effort overall as we won't have to fix things in the interim step.
Sounds good. Taking the axe to this patch and working in NM.
[snip]
The right fix for mkinitrd given the direction we continue to move in there is probably to switch away from nash builtins and just suck in the appropriate utilities into the initrd. But that's not an easy move either.
That's an entire project by itself, I think.
Yep. Hence, I wouldn't try and tie it at all to this set of changes. Which might mean that libdhcp sticks around for a minor case for a little bit longer, but hopefully not that much longer.
KAHN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Upstream mkinitrd needs to understand that no bugs will be fixed in libdhcp from this point on.
On May 21, 2008, at 8:10 AM, Jeremy Katz wrote:
On Wed, 2008-05-21 at 07:43 -1000, David Cantrell wrote:
The driving goal for me has been "get rid of libdhcp fast". So I put this patch together hoping I could merge it in to rawhide sooner rather than later and then have some time to work up a move-to-NM patch. If people want to skip that interim step entirely, I'm cool with that and can go ahead and start moving it to NM entirely. Not knowing how long that would take, I just focused on removing libdhcp for now and leaving our current functionality in place.
Fair enough... I just think that we might as well get the real end goal in place, even if it takes a little bit longer. It will end up saving effort overall as we won't have to fix things in the interim step.
NM will also require support for IPv6 configuration, which I think it lacks now. I can work with dcbw to get that in to NM.
David Cantrell wrote:
On May 21, 2008, at 3:35 AM, Jeremy Katz wrote:
The right fix for mkinitrd given the direction we continue to move in there is probably to switch away from nash builtins and just suck in the appropriate utilities into the initrd. But that's not an easy move either.
That's an entire project by itself, I think.
I was looking at nash while I was trying to figure why my DC7700 (see Fedora test list) wouldn't boot, and pondered building it like busybox, so I could run a proper shell and still do those things.
Then someone said my problem had made it to lkml and that it was an f9 blocker and I stopped wondering about such things:-) I'm not fond of C.
On Tue, 2008-05-20 at 18:40 -1000, David Cantrell wrote:
This patch removes anaconda's use of libdhcp, which also means removing libdhcp4client and libdhcp6client.
Was there a reason these packages weren't culled from upd-instroot ?
Jesse Keating wrote:
On Tue, 2008-05-20 at 18:40 -1000, David Cantrell wrote:
This patch removes anaconda's use of libdhcp, which also means removing libdhcp4client and libdhcp6client.
Was there a reason these packages weren't culled from upd-instroot ?
Is there a reason we list those packages there, instead of providing a comps group?
Kind regards,
Jeroen van Meeuwen -kanarip
On Dec 21, 2008, at 5:45 AM, Jeroen van Meeuwen wrote:
Jesse Keating wrote:
On Tue, 2008-05-20 at 18:40 -1000, David Cantrell wrote:
This patch removes anaconda's use of libdhcp, which also means removing libdhcp4client and libdhcp6client.
Was there a reason these packages weren't culled from upd-instroot ?
Is there a reason we list those packages there, instead of providing a comps group?
We already have to update a file list in the script... having to update both a script in anaconda and a comps group as opposed to just the script means added work.
One thing we should do, though, is switch to specifying more things to install as "we want this file" as opposed to caring as much about the specific package
Jeremy
Jeremy Katz wrote:
On Dec 21, 2008, at 5:45 AM, Jeroen van Meeuwen wrote:
Jesse Keating wrote:
On Tue, 2008-05-20 at 18:40 -1000, David Cantrell wrote:
This patch removes anaconda's use of libdhcp, which also means removing libdhcp4client and libdhcp6client.
Was there a reason these packages weren't culled from upd-instroot ?
Is there a reason we list those packages there, instead of providing a comps group?
We already have to update a file list in the script... having to update both a script in anaconda and a comps group as opposed to just the script means added work.
I said "instead".
-Jeroen
On Dec 21, 2008, at 7:56 PM, Jeroen van Meeuwen wrote:
Jeremy Katz wrote:
On Dec 21, 2008, at 5:45 AM, Jeroen van Meeuwen wrote:
Jesse Keating wrote:
On Tue, 2008-05-20 at 18:40 -1000, David Cantrell wrote:
This patch removes anaconda's use of libdhcp, which also means removing libdhcp4client and libdhcp6client.
Was there a reason these packages weren't culled from upd- instroot ?
Is there a reason we list those packages there, instead of providing a comps group?
We already have to update a file list in the script... having to update both a script in anaconda and a comps group as opposed to just the script means added work.
I said "instead".
We can't use a comps group to have a whitelist of the files we want to include for the images.
Just saying "this set of packages" isn't sufficient unless we're okay with the install images increasing in size to 300 megs[1], which, I'm really not
Jeremy
[1] As of the last time I looked. Maybe somewhat more or less now, but the magnitude should be close
Jeremy Katz wrote:
On Dec 21, 2008, at 7:56 PM, Jeroen van Meeuwen wrote:
Jeremy Katz wrote:
On Dec 21, 2008, at 5:45 AM, Jeroen van Meeuwen wrote:
Jesse Keating wrote:
On Tue, 2008-05-20 at 18:40 -1000, David Cantrell wrote:
This patch removes anaconda's use of libdhcp, which also means removing libdhcp4client and libdhcp6client.
Was there a reason these packages weren't culled from upd-instroot ?
Is there a reason we list those packages there, instead of providing a comps group?
We already have to update a file list in the script... having to update both a script in anaconda and a comps group as opposed to just the script means added work.
I said "instead".
We can't use a comps group to have a whitelist of the files we want to include for the images.
The comps remark goes to PACKAGES, not KEEPFILES.
Just saying "this set of packages" isn't sufficient unless we're okay with the install images increasing in size to 300 megs[1], which, I'm really not
Having PACKAGES in comps isn't mutually exclusive with KEEPFILES remaining in upd-instroot.
-Jeroen
On Dec 21, 2008, at 8:12 PM, Jeroen van Meeuwen wrote:\
Jeremy Katz wrote:
On Dec 21, 2008, at 7:56 PM, Jeroen van Meeuwen wrote:
Jeremy Katz wrote:
On Dec 21, 2008, at 5:45 AM, Jeroen van Meeuwen wrote:
Jesse Keating wrote:
On Tue, 2008-05-20 at 18:40 -1000, David Cantrell wrote: > This patch removes anaconda's use of libdhcp, which also > means removing libdhcp4client and libdhcp6client. Was there a reason these packages weren't culled from upd- instroot ?
Is there a reason we list those packages there, instead of providing a comps group?
We already have to update a file list in the script... having to update both a script in anaconda and a comps group as opposed to just the script means added work.
I said "instead".
We can't use a comps group to have a whitelist of the files we want to include for the images.
The comps remark goes to PACKAGES, not KEEPFILES.
Just saying "this set of packages" isn't sufficient unless we're okay with the install images increasing in size to 300 megs[1], which, I'm really not
Having PACKAGES in comps isn't mutually exclusive with KEEPFILES remaining in upd-instroot.
Then read what I wrote the first time...
"having to update both a script in anaconda" (for the case where there are new files, which is the most common need to have to make any changes) "and a comps groups" (which is what you're proposing) "as opposed to just the script" (what we do now) "means added work"
Jeremy
Jeremy Katz wrote:
Then read what I wrote the first time...
"having to update both a script in anaconda" (for the case where there are new files, which is the most common need to have to make any changes) "and a comps groups" (which is what you're proposing) "as opposed to just the script" (what we do now) "means added work"
You're right. Two lists in one file is less work then two lists in two files.
-Jeroen
Jesse Keating wrote:
On Tue, 2008-05-20 at 18:40 -1000, David Cantrell wrote:
This patch removes anaconda's use of libdhcp, which also means removing libdhcp4client and libdhcp6client.
Was there a reason these packages weren't culled from upd-instroot ?
Nope, forgot.
anaconda-devel@lists.fedoraproject.org
-
Bill Nottingham -
Chris Lumens -
David Cantrell -
Elliot Peele -
Jeremy Katz -
Jeroen van Meeuwen -
Jesse Keating -
John Summerfield