Bill Rugolsky Jr. wrote:
Beyond that, agreement tends to dissolve, because intended uses vary widely.
That was sort of my point...about having a consensus view not being ignored. Good luck finding that consensus. Maybe a 460Meg "minimal" doesn't work for everyone...but if it works for 80% of the userbase or for the intended audience or for an intended use...then maybe that 460Meg minimal install is the best fit for the development resources on hand...and we need to move on.
And there is a logic fault involved with any argument that says you can assuredly create any sort of install process meeting the competing interests of easy maintainability from the development side, easy of use/simplification for the non-technical audience...and easy of use/customization for the technically proficient user. I humbly submit there are trade-offs invovled and there is no perfect solution. And in the final analysis...the technically savvy users have tools already to do customized installs...kickstart just makes more sense for a lot of situations where technically proficient users want the option of being lazy, instead of pipedreaming about an installer that meets their specific usage interests. And if kickstart doesn't do it for you and you are in the 0.1% of people who know they need a very exactly specific install where you can't go back in with a post install script and uninstall things you don't need because you have exactly 200Megs of harddrive space you can use for the install...well rolling your own isos is probably best...anaconda-runtime also exists for a reason. There is an intended audience for rhl....and i would again humbly suggest that putting in a lot of easy to find options in the default iso images meant for the 0.1% of the userbase outside of the intended audience who should be using kickstart or anaconda-runtime to make extremely customized installs...is going to lead to problems with the intended userbase and waste developer time which could be spent streamlining the installer and debugging the installer for the intended install situations. The people who KNOW they need to squeeze a Red Hat install into 100 Megs of harddrive space, are going to need to know far more about other avenues of streamlining and customization to get things to work just like they want them to. 30Megs just for the default kernel modules alone....yippie!!!!!...at some point you build a customized iso to get exactly what you want.
The way forward for everybody, is to work out how to create a 2 stage install that moves a lot of the package selection crap out of anaconda...and into a firstboot situation...a firstboot situation where you get access to the actually system resources...and not those resources available in the installer ramdisk image. So what if anaconda's "minimal install" includes a set of packages that you end up not wanting to install. Harddrive space is CHEAP. We need to find one and only one distro provided "balanced" minimal install sequence that provides enough tools so that you can come back in after a firstboot and do a wealth of customization..including package removal...via repositories...via a well baked r-c-packages..via personalized scripts..etc....outside of the limited ramdisk anaconda gets access to.
If being able to remove packages post 1st stage install is the sticking point...that needs to be worked on. Clean package removal is important in a number of situations...even for the intended non technically savant audience. Figure out how to do that cleanly...and you help everyone...not just the 0.1% of people who need to do a 73Meg harddrive firewall install. Once we recognize the package removal is a hard problem...that doesn't mean we should work around that problem with craptastic kludges that complicated the installer process. We need to tackle the hard problem of how to do package removals well...and streamline the 1st stage installer....that is a better use of the limited developer time....its the biggest long term bang for the buck/doughnut/beer/pizza/long winded patriotic essays/whatever you use to bribe developers with to do yer bidding.
If you need to worry about having only 200Megs of Harddrive space or only 4 megs of memory at this point in the game...you really should be rolling yer own media sets or something other than expecting the default rhl image to cater to systems limitations for which predate cobol....anaconda-runtime exists for a reason.
Separating packages into executables and libraries is a good idea not only because it allows multiple libfoo* installs, but also because it saves space when all that one wants are the libs, and not the default front-end application, which may have additional dependencies.
Saves space....i would say that at this point for the "intended" audience for rhl...saving space is not a priority. Diskspace is cheap. But I'm sensing a very technical and very drawn out debate about what the pro's and con's to very fined grained packaging is. And the only people really qualified to wade into this one...are people who should be busy fixing high priority bugreports...instead of posting to this thread or sending email to me or you offlist. But I imagine taking a good hard look at what it would mean to allow multiple libfoo* installs would be another very enlightening discussion of the trade-offs among the interests of difference segments of the userbase..
-jef"if only rpm-analyzer worked not only with hdlists but with installed rpmdb's...gui reverse dependancy trees are neat"spaleta