system-config-network-tui not part of base install... wtf
On 07/26/2012 06:33 PM, Reindl Harald wrote:
>
>
> Am 26.07.2012 19:27, schrieb Karanbir Singh:
>> On 07/26/2012 04:42 PM, Fernando Cassia wrote:
>>> My opinion after this experience is that it'd help for CentOS to
>>> include system-config-network-tui as part of the base install.
>>
>> Can you be a bit more specific about what you mean by a 'base install' ?
>> Its not actually possible to get a minimalist @base only install without
>> kickstarting the installer instance - at which point you might as well
>> +<package> whatever you need.
>
>
> says who?
erm, have you looked at the anaconda setup group selections ? None of
them default to an @base only install.
> you get a completly stripped down setup which
> no network, no editors like nano and have to
> do your first network config with echo to the
> config files which takes around 30 seconds
Are you saying here that even when you select a Desktop or Workstation
install profile you end up with a minimalist install ? I find that
pretty hard to believe.
system-config-network-tui not part of base install... wtf
On 07/26/2012 06:59 PM, Keith Keller wrote:
>> Who was the genius that decided that system-config-network-tui should
>> NOT be part of the base CentOS 6.3 install ??
>>
>> Not to mention it has insane deps like wifi firmware packages... not
>> really if all you want to do is configure eth0 from the command
>> line...
>
> Wouldn't both of these decisions have been made upstream?
yes and no. We have some liberty to change / adapt the install class's
based on what comes down stream ( remember, we normalise the distro core
to remove variant specific / pricing specific options from upstream ).
The install classes and groups are things that we build, locally, in
CentOS - in an attempt to match what is pushed downstream. If there are
issues, its certainly worth testing to see if its a centos induced issue
or not.
system-config-network-tui not part of base install... wtf
On 07/26/2012 08:41 PM, Keith Keller wrote:
> On 2012-07-26, Karanbir Singh <mail-lists@karan.org> wrote:
>> On 07/26/2012 06:59 PM, Keith Keller wrote:
>>>> Who was the genius that decided that system-config-network-tui should
>>>> NOT be part of the base CentOS 6.3 install ??
>>>>
>>>> Not to mention it has insane deps like wifi firmware packages... not
>>>> really if all you want to do is configure eth0 from the command
>>>> line...
>>> Wouldn't both of these decisions have been made upstream?
>> yes and no. We have some liberty to change / adapt the install class's
>> based on what comes down stream ( remember, we normalise the distro core
>> to remove variant specific / pricing specific options from upstream ).
>>
>> The install classes and groups are things that we build, locally, in
>> CentOS - in an attempt to match what is pushed downstream. If there are
>> issues, its certainly worth testing to see if its a centos induced issue
>> or not.
> That sounds reasonable enough (and I wondered about that for the first
> question).
>
> What about the second issue? Would CentOS change RPM dependencies from
> upstream (if it were possible)? That seems a lot less likely to me.
We would not change the dependencies of an RPM, we might change the
install groups in the comps file.
The reason it is not included in CentOS now is because it is not
included upstream.
For us to change it, there would need to be a compelling reason.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
07-27-2012, 12:12 PM
Karanbir Singh
system-config-network-tui not part of base install... wtf
On 07/27/2012 02:41 AM, Keith Keller wrote:
>> The install classes and groups are things that we build, locally, in
>> CentOS - in an attempt to match what is pushed downstream. If there are
>> issues, its certainly worth testing to see if its a centos induced issue
>> or not.
...
> What about the second issue? Would CentOS change RPM dependencies from
> upstream (if it were possible)? That seems a lot less likely to me.
I did'nt mean to imply rpm level changes - as Johnny already clarified,
we dont do that. Every package is built and delivered with the intent of
looking as close to upstream as possible.
So to clarify what I did mean : upstream has different variants, and we
need to normalise those. Sometimes its tricky. Eg: a 'minimal' install
option for their RHEL-6-Server looks a bit different from
RHEL-6-Workstation or RHEL-6-ComputeNode. When we deliver a CentOS-6, we
also have a minimal install option that tries to get the best match for
the user. If there was something totally whacked out, we might then need
to rename and add another group. eg. assume that RHEL-6-Workstation has
a LibreOffice component included, which might be considered reasonable
on a workstation, we would not want that to cascade into the CentOS-6
minimal install. A potential compromise there would be a regular
'minimal install' option for CentOS-6, as well as a 'Mimimal-Workstation
install' option.