Poll: Customized Fedora

James McDermott jmcdermo at redhat.com
Fri Mar 26 20:48:08 UTC 2004


On Fri, 2004-03-26 at 15:25, Adam T. Gautier wrote:
> Also, I am not thinking that the any joe schmo would use this service.  
> It would really be for IT managers, developers, and technical hobbiest.  
> They would choose the packages they wanted available to be installed.  
> Instead of using the one size fits all Fedora install, which also has 
> the contraint of only using packages allowed by RedHat, no third party 
> packages.

The main value seems to be that you would allow trees which are not
blessed yet, betas, custom packages etc... that did not make the main
distro list.

Expanding on that thought it would seem a service to check and sign
these packages would be a nice add-on. That way the purchaser could rest
somewhat easier that malicious code didnt make it in under the radar. 

> That is why I want to base the service on existing distributions.  Open 
> source is just standing on the shoulders of giants.  A user could throw 
> a bunch of packages together and hope that they worked but that is their 
> perogative, I could do that now if I wanted but I know it is a waste of 
> time.

yeah, pulling packages from multiple vendors eliminates some of the
signing concerns. It would open up dependency issues though. 
The only way this really cleans itself is to go with one vendor per
buildable tree and stick with beta realeases, or custom packages to sit
on top of that specific distribution. Otherwise you will spend all your
time chasing dependencys and building packages.

The other big item looks like it would be the audience you are going
after. The IT managers etc really want supported products, and by the
very nature of building a "youix" distro with custom packages you would
be taking that away from them. I agree there are very likely groups
interested in something along these lines, just not sure thats the one.

If you built discs similar to driver discs though.... I dont see why you
couldn't supplement a distro with custom packages. Seems like it would
be a neat piece in anaconda, to allow custom pluggable discs with a
package set that fit neatly into kickstart and all the subroutines,
network readable, signed etc... This would open the door for many
companies to package their wares for the installer. 

And then you would not be stuck on the following concerns, which would
essentially mean maintaining your own distro. 

> >that the
> >installer is consistent and easy to use, etc, etc, and 
> >
> Agreed, I would work to make the existing installers better.
> 
> >then provide some means
> >of ongoing maintenance (even if it's as simple as "here's a diff file, there's
> >the code, have fun").
> >
> >  
> >
> I agree, Red Hat, Mandrake, and Suse already have thriving businesses 
> based on the support model.  I expect users to get their support packs 
> and package upgrades etc from them.  I just think there is a group of 
> people that want to define their own distribution parameters: look and 
> feel, packages, configuration, etc... If these systems are based on say 
> Fedora why can't they get support from these mailing lists.  Would it 
> not be the same as installing fedora and editing a file in /etc?
> 
> >This process is not conduive to, nor indeed feasable, via a "public one size
> >fits all" webpage service.
> >
> Why not?
> 
> >  If you have something else in mind, like a
> >"pre-customize Fedora Core with your own logos" or something, that's another
> >thing entirely.  You could just release your own version of fedora-logos.
> >
> >  
> >
> Creating custom RPMs is one way to go... But people use technology to 
> implement solutions not to install software.  I am just trying to 
> provide another distribution of complete solution sets not just 
> installable software.  Sure I could create a custom RPM of postfix to 
> implement a specific part of a solution, I could also create a 
> pre-configured distribution that I know will have the correct packages 
> for the solution.  Just seems like another way to go...
> 





More information about the fedora-list mailing list