SCIENTIFIC-LINUX-USERS Archives

September 2011

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Sat, 17 Sep 2011 16:25:10 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (36 lines)
On Sat, Sep 17, 2011 at 2:16 PM, Akemi Yagi <[log in to unmask]> wrote:
> On Sat, Sep 17, 2011 at 1:15 AM, Tanmoy Chatterjee <[log in to unmask]> wrote:
>> On Fri, Sep 16, 2011 at 4:19 AM, Stefan Lasiewski <[log in to unmask]> wrote:
>
>>> Does SL6 support the yum-plugin-security [1] plugin? This would be very
>>> useful in addressing security advisories.
>
>> In this respect I want to add - does the yum "PRESTO" plug-in works with SL6.1?
>
> Well, this is "off-topic" in this thread, but anyway...
>
> There is no support for yum-presto in SL. My [very wild] guess is
> that, because SL was primarily serving universities or research labs
> that maintain their own local repos or are on fast Internet(2), use of
> deltaRPMs was not really advantageous.

There's also the broader presence of the verifiable SL repositories.
Our favorite upstream vendor has to deal with a lot of commercial
customers hitting their corporate, authenticated and channel managed
servers for individual channels where a customer has access to this
channel with that license, and that channel with that license, and
channel access may be swapped to different hosts, and chaos ensues.

SL and other rebuilds of The Upstream Vendor's tools simply publish
the whole thing in a more accessible and browseable format. The result
is better failover, as long as enough mirrors are willing to stay up
and public.

> I'm not sure if the SL team would consider adding the yum-presto
> support now that there is an increasing number of SL users [1] that
> might benefit from it. No doubt it will require a good amount of
> additional resources and work on the infrastructure etc.

I'd be curious how much of the traffic is merely yum repodata parsing,
and home is actual downloading of packages.

ATOM RSS1 RSS2