[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Package management.

On Sat, 15 Mar 2003, Marcus Leonard wrote:

> Forgive me if this has been discussed in detail before; I'm new to
> this list, so I've been going through previous lists but haven't
> found anything yet that really addresses it (until I get flamed
> and told...)

No, no...this is perfect timing. The other flamewar I'm in the list seems
to be winding up. mharris, just won't leave it well enough alone, keeps
butting in ruining the whole aggressive flamewar feeling of the thread
with "information" and "facts" and "reasonable opinions."  But now yer
here, so I can just flame you..before someone more civil and
knowledgable steps in and ruins my fun.

> But with RH 8.0, package management seemed to go backwards.
> redhat-config-packages will pretty much only install off the
> CDs (don't yell - I said pretty much); no configurable FTP/HTTP
> repositories (that I'm aware of), no apparent acknowledgement
> of apt so far, etc. Most people appear to agree that the tool
> is too simple as it stands. There is a mismatch here: given
> that everything else in the distro is getting so polished, this
> lack seems conspicuous.


Red Hat's internal culture seems to becoming more and more concerned about
security and supportabiliy all through its product offerings...including
security with regard to 3rd package installs. I think the paragraph
from that FAQ states the issues nicely...issues of security and trust.
Should Red Hat make it easy for you to point and click you way to install
or more importantly UPGRADE packages that don't live up to Red Hat's QA
standard? I don't necessarily think so.  package automation tools can do a
lot behind the scene, replacing Red Hat packages that you may not be
completely aware of, if you are a newbie, that could very quickly lead to
a system configuration Red Hat cannot provide support for.  If yer not a
newbie, and know  enough to understand the risks of upgrading to 3rd party
packages in a blind automated way....then you probably know enough to go
grab, something like apt or yum or grab. I see no problem whatsoever
having users, who want to customize their system and know enough to do it
safely, go out on  the internet and download ONE rpm by hand...and install
ONE rpm by hand, to get a community based packaging tool up and running.
I do have a problem however, including a packaging tool like apt-get in
Red Hat, and having  someone like my mom, try to use it to download a
program she wants from some random apt repository, and having apt-get try
to uninstall such core  things as glibc and replace them with a non Red
Hat version. Sounds funny doesn't. I've seen people
show up in irc complaining about situations like that with apt, just
recently in fact.

If Red Hat included apt into its distro, there would be an expectation
that Red Hat would be able to support it and clean up after its messes,
when it goes wrong or when it installs a trojaned application.  You have
to TRUST apt repository creators, and now I may TRUST them, and you may
TRUST them... maybe Red Hat should NOT TRUST them, out of the box...if
there is no way for Red Hat to be assured that the packages they provide
meet a minimum QA specification.

Do you give the power users what they need? Or do you protect newbies with
a bad downloading addiction from hurting themselves. Hmm...which is the
better business model?

I am hopefully that the linux user community can step up and provide an
addon package management solution that addresses some of the security and
trust issues that current systems have.

> Phoebe looks good (actually I'm pretty impressed overall),
> but I still wonder about the conspicuous absence of advanced
> package management. The other popular distros are conspicuous
> by their inclusion, often, of several packages that do the same
> thing.

I guess the other distros aren't as focused on security....shrug..you'd
have to talk to them about it.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]