DNF: why does it refresh metadata all the time

[Mat Booth]

On 20 June 2014 11:50, Reindl Harald <h.reindl at thelounge.net> wrote:

>
>
> Am 20.06.2014 12:36, schrieb Mat Booth:
> > On 20 June 2014 11:19, Reindl Harald <h.reindl at thelounge.net <mailto:
> h.reindl at thelounge.net>> wrote:
> >
> >
> >
> >     Am 20.06.2014 11:57, schrieb Mat Booth:
> >     > On 20 June 2014 10:19, Reindl Harald <h.reindl at thelounge.net
> <mailto:h.reindl at thelounge.net>
> >     <mailto:h.reindl at thelounge.net <mailto:h.reindl at thelounge.net>>>
> wrote:
> >     >
> >     >     Am 20.06.2014 08:55, schrieb drago01:
> >     >     > On Thu, Jun 19, 2014 at 8:59 PM, Jared K. Smith
> >     >     > <jsmith at fedoraproject.org <mailto:jsmith at fedoraproject.org>
> <mailto:jsmith at fedoraproject.org
> >     <mailto:jsmith at fedoraproject.org>>> wrote:
> >     >     >> On Thu, Jun 19, 2014 at 2:01 PM, Reindl Harald <
> h.reindl at thelounge.net <mailto:h.reindl at thelounge.net>
> >     <mailto:h.reindl at thelounge.net <mailto:h.reindl at thelounge.net>>>
> >     >     >> wrote:
> >     >     >> Whether you like it or not, one of the most common
> complaints about yum
> >     >     >> (especially from people coming from another package
> management system) is
> >     >     >> that it seems slow because of the necessity to download the
> metadata.  The
> >     >     >> DNF developers -- in trying to address this common
> complaint -- had solved
> >     >     >> it by handling metadata in a different way.  They've also
> added settings so
> >     >     >> that power users like you and I can tune it to better fit
> our particular
> >     >     >> needs.
> >     >     >>
> >     >     >>> and *no* traffic is not cheap everywhere, by far not
> >     >     >>
> >     >     >> I probably understand this better than a lot of people on
> this list, as I've
> >     >     >> been on a bandwidth-limited connection for the past nine
> years.  Only in the
> >     >     >> past month have I been able to get high speed internet in
> my home that
> >     >     >> wasn't limited to a few gigabytes per month.  So yes, I
> completely
> >     >     >> understand that traffic isn't cheap (or fast) everywhere.
> >     >     >
> >     >     > It should be at least smart enough to not do it on mobile
> broadband
> >     >     > (like packagekit does)
> >     >
> >     >     how should it do that?
> >     >
> >     >     it's imagination that any software knows anything about the
> internet connection
> >     >     even 11 years ago with a 56k modem that access was shared for
> my LAN and so
> >     >     the only thing the notebook knew about the inernet was
> "appears to be slow"
> >     >
> >     > IIRC, NetworkManager's DBus API should be able to give you that
> information
> >
> >     from where should it get that information if your network connection
> is
> >     a Gigabit-Ethernet LAN to the router with a slow DSL upstream?
> >
> >     your whole machine has no idea about your WAN connection
> >
> > Woah there... The suggestion was to simply let it be "smart enough to
> not do it on mobile broadband" to which you
> > asked "how?"
> >
> > I answered only that question
>
> again:
>
> * 3G stick aka mobile broadband as WAN connection
> * that WAN connection is shared in the LAN
> * the single machines don't know anything about the WAN connection
>
> believe it or not, but here in austria it's not uncommon to get a
> box with 3G and on the other end a ethernet-port where you connect
> your devices and have some hundret MB per month
>
> in the meantime many of that packages are going in the direction
> ulimited traffic, but that's nothing you can be sure about as
> OS supplier
>
>
Well sure, but there's no sense in throwing out all imperfect solutions
because of a desire for perfection. Don't you agree that a good first step
would be to teach DNF how to talk to NetworkManager?

3G internet is common in my locale too -- this would at least cover the use
case of connecting with a 3G dongle or tethered mobile phone.

-- 
Mat Booth
http://fedoraproject.org/get-fedora
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140620/0159168c/attachment.html>