On Wed, 2010-09-01 at 20:14 -0400, Matthew Miller wrote:
On Wed, Sep 01, 2010 at 01:09:36PM -0400, seth vidal wrote:
> > > I would start with the @core comps group (even with a smaller set) and
> > > then add groups of packages creating a server feature. This will build
> > > the server platform from down will make possible to check the
> > > dependencies and to validate whether the set works as expected.
> > After all, "More with Less" is principle #1. :)
> okay
>
http://skvidal.fedorapeople.org/misc/core-f14-resolved.txt
> that's f14-core resolved into a bare chroot.
> start there.
Cool. A few things strike me as potentially troublesome, like cairo, since
that's prone to update-requirements-to-suit-the-latest-desktop-things. But
paring down the list can happen over time.
How would this server branch interact with Fedora, um, core? Would we
configure both the server repo and the main repo, with the server repo set
to be a preferred source via yum crack^H^H^H^H^H magic?
>From the repo compose side, presumably the packages would inherit from the
corresponding main Fedora release, and be forked only if we need to change
them.
my opinion:
a server 'spin' is a ks file like:
install
lang en_US.utf8
keyboard us
url --url fillinurlhere
network --device eth0 --onboot no --bootproto dhcp --hostname localhost
firewall --disabled
authconfig --enableshadow --passalgo=sha512
selinux --enforcing
timezone --utc America/New_York
bootloader --location=mbr --driveorder=sda --append=""
%packages --nobase
@core
and let the admin do the rest.
If you want to get clever you make the inverse of a yum plugin like
'appmarket'. You prune out all the stuff that no server should ever have
near it from search results.
-sv