FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS Development

 
 
LinkBack Thread Tools
 
Old 08-02-2011, 04:45 PM
夜神 岩男
 
Default Centos server installation

On 08/03/2011 01:32 AM, Ljubomir Ljubojevic wrote:
> Karanbir Singh wrote:
>> On 08/02/2011 05:01 PM, Les Mikesell wrote:
>>>> Anyway, wouldn't this break "binary compatibility with upstream"?
>>> Agreed - it is something that upstream should provide too. Or at least
>>> a yum group or list of packages in a form that yum would understand to
>>> install them later.
>>>
>>
>> So the interesting thing about that is - that no, it wont break upstream
>> compatibility; since the groups that are put in are done by us -
>> remember that upstream has varients that we dont, and their process and
>> policy around those varients depends on various non technical factors (
>> eg. how much money you paid for the subscription that in turn got you
>> the install media ).
>>
> Is it possible to create yum groups that overlap with other groups? So
> we/they/whoever could add several selected groups. This means that one
> package could be in several groups.

I think that happens pretty regularly and should be as harmless as

yum install $EXISTING_PACKAGE

-Iwao
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 08-02-2011, 04:54 PM
Les Mikesell
 
Default Centos server installation

On 8/2/2011 11:25 AM, 夜神 岩男 wrote:
>
>> Agreed - it is something that upstream should provide too. Or at least
>> a yum group or list of packages in a form that yum would understand to
>> install them later.
>
> This was discussed, exactly the way you are stating things on one side
> "wouldn't it be nice if..." VS "the uninformed are the majority who
> choose the 'everything' option and when things break they assume the
> whole distro sucks and ditch it" on the other.

It's not an either/or decision if someone who understands the
potentially conflicting packages picks one (and only one) to include in
the 'everything' set.

> Which would you prefer be the newcomer impression of CentOS? A system
> that works well with adequate defaults but that can be explored to the
> heart's content (which entails research -- on any OS -- how many people
> do "everything" AIX installs -- they either don't do them or receive AIX
> package selections that are strict defaults with nothing further
> vendor-provided?) or one that gets overloaded with conflicts and breaks
> because too many conflicts are installed and things that are supposed to
> be simple, like starting or stopping slapd, become complex in ways
> unknowable to the user?
>
> In short:
>
> The chance that a knowledgable system administrator is going to be able
> to research how packages interact in a desired setup...
>
> ...is a lot higher than...
>
> ...the chances that the average person who is prone to click
> "everything" will know how to manage the situation he's put himself in.

What situation would that be if someone vetted the packages and
'everything' didn't include conflicts? Wasting a dollar's worth of disk
space?

> This *was* a feature in the past and was removed for a reason. You can
> head back to FESCo and re-argue it, but I found the case for removal
> compelling, particularly with the 'yum install "*"' option available for
> those who know what they are doing -- and that begins with understanding
> why the "s are necessary in the command.

Ummm, _what_?

> This was a revealing threshold, as it turned out once the feature was
> removed -- most of the complaints/questions on the users@fp.o list about
> removal were from people who really didn't know what quotes do in
> bash... which sort of validated the whole debate in favor of removal
> after the fact. This was the precise demographic that had no business
> clicking "everything" and was the only group clamoring for the
> reinstatement of @everything.

'everything' should not mean "*". It should mean everything that is
sensible, according to someone who actually is familiar with all of
them. I'd be perfectly happy if it didn't include *gcj*, for example,
since I can't imagine that as ever having been good for anyone. And
while I'd prefer sendmail over postscript I'd be able to deal with
someone else making an informed choice there.

> There is history behind this decision. Of course, CentOS is not
> upstream, so it could go its own way, but I think thoughtful
> contemplation of the issue at hand (making a dangerous edgecase widely
> available on an enterprise-level system) they will likely stick with the
> status quo.

I know there is a history. I used to use everything installs, found it
useful in discovering and testing programs, miss it, and don't believe
that the people you think you are 'protecting' by omitting it are going
to do better at choosing non-conflicting sets by themselves given yum
and a list of thousands of package names than someone who was involved
in choosing the set included in the distribution could.

But, something else that I've always wanted to see might be even better.
I've always thought that there should be a push-button way to export
your list of installed packages (and I suppose this should include
repositories...) so that anyone who thinks he has configured the perfect
setup for any particular usage could publish it, and anyone who wanted
to duplicate that setup could do it in a completely automated way.

--
Les Mikesell
lesmikesell@gmail.com

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 08-02-2011, 05:23 PM
夜神 岩男
 
Default Centos server installation

On 08/03/2011 01:54 AM, Les Mikesell wrote:
> On 8/2/2011 11:25 AM, 夜神 岩男 wrote:
>>
>>> Agreed - it is something that upstream should provide too. Or at least
>>> a yum group or list of packages in a form that yum would understand to
>>> install them later.
>>
>> This was discussed, exactly the way you are stating things on one side
>> "wouldn't it be nice if..." VS "the uninformed are the majority who
>> choose the 'everything' option and when things break they assume the
>> whole distro sucks and ditch it" on the other.
>
> It's not an either/or decision if someone who understands the
> potentially conflicting packages picks one (and only one) to include in
> the 'everything' set.

Then it wouldn't be @everything, now would it?

And that is how spins get born.

>> In short:
>>
>> The chance that a knowledgable system administrator is going to be able
>> to research how packages interact in a desired setup...
>>
>> ...is a lot higher than...
>>
>> ...the chances that the average person who is prone to click
>> "everything" will know how to manage the situation he's put himself in.
>
> What situation would that be if someone vetted the packages and
> 'everything' didn't include conflicts? Wasting a dollar's worth of disk
> space?

Once again, removing something from everything makes it not everything,
it makes it a "functional subset" known sometimes as a "system default
installation" or a "spin" depending on how extensive the selections
divert from the upstream view.

>> This *was* a feature in the past and was removed for a reason. You can
>> head back to FESCo and re-argue it, but I found the case for removal
>> compelling, particularly with the 'yum install "*"' option available for
>> those who know what they are doing -- and that begins with understanding
>> why the "s are necessary in the command.
>
> Ummm, _what_?

You are underestimating the general public's ability to be fickle about
technology they get for free yet do not understand.

> 'everything' should not mean "*". It should mean everything that is
> sensible, according to someone who actually is familiar with all of
> them. I'd be perfectly happy if it didn't include *gcj*, for example,
> since I can't imagine that as ever having been good for anyone. And
> while I'd prefer sendmail over postscript I'd be able to deal with
> someone else making an informed choice there.

And how is upstream to read your mind and know to not include gcj for
your concept of "everything" and exclude something else for someone
else's view of "everything". This sort of gets to the root of the
problem. I think we're having an Aristotle moment in logical semantics
where everything equals everything and not something other than everything.

> I know there is a history. I used to use everything installs, found it
> useful in discovering and testing programs, miss it, and don't believe
> that the people you think you are 'protecting' by omitting it are going
> to do better at choosing non-conflicting sets by themselves given yum
> and a list of thousands of package names than someone who was involved
> in choosing the set included in the distribution could.

But yum install "*" hasn't gone away. Are you saying this is too hard?

> But, something else that I've always wanted to see might be even better.
> I've always thought that there should be a push-button way to export
> your list of installed packages (and I suppose this should include
> repositories...) so that anyone who thinks he has configured the perfect
> setup for any particular usage could publish it, and anyone who wanted
> to duplicate that setup could do it in a completely automated way.

Now you're talking. This is a great idea -- and I don't know a way of
doing this other than through a script that parses the output of "yum
list installed" -- which is something I did once upon a time to create
.ks files with a little more ease than I had been doing. A lot of people
do the same thing by being very patient with a click-through Anaconda
install and getting the list from the generated .ks file, but that is
sort of a pain and doesn't tell you anything about what you discovered
after the installation, which I think is your real point.

I never made the leap to making it a push-button feature on the desktop
(though that would be easy now that its thought of) or moving as far as
to think of exporting the output into an Anaconda profile selection (the
way you can select "workstation" or "development" or "server" or
"minimal") -- but that would be pretty cool too and perhaps more cleanly
achieve the effect you're after.

-Iwao
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 08-02-2011, 05:26 PM
Ljubomir Ljubojevic
 
Default Centos server installation

Les Mikesell wrote:
>
> 'everything' should not mean "*". It should mean everything that is
> sensible, according to someone who actually is familiar with all of
> them. I'd be perfectly happy if it didn't include *gcj*, for example,
> since I can't imagine that as ever having been good for anyone. And
> while I'd prefer sendmail over postscript I'd be able to deal with
> someone else making an informed choice there.

You meant "postfix" in last sentence?
--

Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

Google is the Mother, Google is the Father, and traceroute is your
trusty Spiderman...
StarOS, Mikrotik and CentOS/RHEL/Linux consultant
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 08-02-2011, 06:04 PM
Les Mikesell
 
Default Centos server installation

On 8/2/2011 12:23 PM, 夜神 岩男 wrote:
>
>> It's not an either/or decision if someone who understands the
>> potentially conflicting packages picks one (and only one) to include in
>> the 'everything' set.
>
> Then it wouldn't be @everything, now would it?

Call it "everything that's not broken" then.

> And that is how spins get born.

That's the reason spins need to be born. Because there's not a good way
to manage a list of packages. Well, that and repository policies that
pretty much guarantee that you'll need packages from third party repos.
Almost anything that spins can do could be done with a minimal install
to the point that yum works and a package list.

>>> This *was* a feature in the past and was removed for a reason. You can
>>> head back to FESCo and re-argue it, but I found the case for removal
>>> compelling, particularly with the 'yum install "*"' option available for
>>> those who know what they are doing -- and that begins with understanding
>>> why the "s are necessary in the command.
>>
>> Ummm, _what_?
>
> You are underestimating the general public's ability to be fickle about
> technology they get for free yet do not understand.

No, I'm saying the people who haven't already memorized all of bash's
quirky syntax rules are precisely the ones who would benefit most from
having the largest working set of programs dropped in their lap to
explore, man pages and all. And leaving them on their own to figure out
which few were the ones that you already know are bad to install
together is a disservice.

>> 'everything' should not mean "*". It should mean everything that is
>> sensible, according to someone who actually is familiar with all of
>> them. I'd be perfectly happy if it didn't include *gcj*, for example,
>> since I can't imagine that as ever having been good for anyone. And
>> while I'd prefer sendmail over postscript I'd be able to deal with
>> someone else making an informed choice there.
>
> And how is upstream to read your mind and know to not include gcj for
> your concept of "everything" and exclude something else for someone
> else's view of "everything".

That should be an 'informed' decision. I'm assuming that the
person/group who decides what packages are to be included knows
something about them, but why assume that about anyone else? You don't
have to read my mind to know why gcj is wrong to inflict on people, just
try to run a standard java program with it.

> This sort of gets to the root of the
> problem. I think we're having an Aristotle moment in logical semantics
> where everything equals everything and not something other than everything.

No, there are people who know what things don't belong together (hence
the point that "*" or a real 'everything" is bad). But that should not
lead to a conclusion that they should leave the rest of the world to
make that discovery the hard way by omitting a choice that installs all
the programs that do work together.

>> I know there is a history. I used to use everything installs, found it
>> useful in discovering and testing programs, miss it, and don't believe
>> that the people you think you are 'protecting' by omitting it are going
>> to do better at choosing non-conflicting sets by themselves given yum
>> and a list of thousands of package names than someone who was involved
>> in choosing the set included in the distribution could.
>
> But yum install "*" hasn't gone away. Are you saying this is too hard?

No, I'm saying it is not quite the right set, and the person/group who
decided 'everything' is bad knew why. Discovering why by myself might
be hard, though.

>
>> But, something else that I've always wanted to see might be even better.
>> I've always thought that there should be a push-button way to export
>> your list of installed packages (and I suppose this should include
>> repositories...) so that anyone who thinks he has configured the perfect
>> setup for any particular usage could publish it, and anyone who wanted
>> to duplicate that setup could do it in a completely automated way.
>
> Now you're talking. This is a great idea -- and I don't know a way of
> doing this other than through a script that parses the output of "yum
> list installed" -- which is something I did once upon a time to create
> .ks files with a little more ease than I had been doing. A lot of people
> do the same thing by being very patient with a click-through Anaconda
> install and getting the list from the generated .ks file, but that is
> sort of a pain and doesn't tell you anything about what you discovered
> after the installation, which I think is your real point.

Usually it takes a lot of fiddling to get the right set in the first
place, especially when you need to try some from different 3rd party
repos and work around the likely conflicts there.

> I never made the leap to making it a push-button feature on the desktop
> (though that would be easy now that its thought of) or moving as far as
> to think of exporting the output into an Anaconda profile selection (the
> way you can select "workstation" or "development" or "server" or
> "minimal") -- but that would be pretty cool too and perhaps more cleanly
> achieve the effect you're after.

I think this could work on two levels - one as a local tool to duplicate
machines (and perhaps it should include package version information to
hold the update levels together) and another to mostly replace the
concept of spins with a public central location to publish package lists
with some commentary on why you chose that particular set and what has
to be done to configure them.

--
Les Mikesell
lesmikesell@gmail.com

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 

Thread Tools




All times are GMT. The time now is 09:29 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org