'everything' install option in FC5test1
seth vidal
skvidal at phy.duke.edu
Sat Nov 26 16:06:02 UTC 2005
On Sat, 2005-11-26 at 16:02 +0000, Willem Riede wrote:
> On 11/26/2005 10:35:27 AM, Matthew Miller wrote:
> > On Sat, Nov 26, 2005 at 02:32:17PM +0000, Willem Riede wrote:
> > > >that it shouldn't include language-specific packages. Some people think
> > > >it should. With multiple repositories, should it include all of the
> > > >packages from all of the repositories? What happens if there are
> > > That one is solvable by calling it "everything from core" and having a
> > [...]
> >
> > But if it is just "everything from core", what's the argument for having it,
> > then? From what I've heard from people who like having Everything, they want
> > it because they want every possibility pre-installed -- which this wouldn't
> > be. It'd just be "a bunch of stuff that's useful in a core distribution,
> > the majority of which isn't ever going to be useful or relevant to any one
> > specific installation".
>
> Having "everything from every repo that I identified" installed is not a safe
> option to provide. Many repos hold updates to core packages that should not be
> blindly chosen.
>
> And frankly, I'd vote for not having an everything option at all, because your
> qualification of the majority not being useful or relevant to the user
> defenitely holds independant of how wide an everything net you cast.
>
> The only reason users go for it IMHO is that they they don't know what they
> want or need. They end up with stuff installed they don't know they have, even
> though they might use it if they knew. With yum it is so easy and convenient
> to just pull in a package that you want to try once you learn about its
> existance, that I don't see the value of speculatively pre-installing.
>
> But if there is going to be an "everything", again IMHO, it should be limited
> to core.
yum --disablerepo='*' --enablerepo='base'
--enablerepo='updates-released' install '*'
that would be an 'install everything, just from core'
-sv
More information about the fedora-devel-list
mailing list