Bug 154990

Stano is currently working on this one.

Michael, how did autorefresh work? If the ID in media.1/media did not match, it did refresh?

Michael, how did autorefresh work? If the ID in media.1/media did not match, it did refresh?

Depends on the kind of source.

- Associated with each Source is an autorefresh flag. Default value on creation 
  of a Source is:

  - TRUE for non SuSE sources

  - FALSE for SuSE sources, UNLESS "volatile_content" flag is set int the 
    content file.
  
- Before enabling a Source the first time, Source::refresh was called, if 
  autorefresh is TRUE for this Source.

- Source::refresh is a NOOP if media is CD/DVD. Otherwise the Source 
  implementations refresh was called, if the Source media_id has changed.

  - Susetags refreshes if the 2nd line in media.1/media changed.

  - Yum refreshes if the sha1sum of repomd.xml has changed (that's been used as 
    media_id for a Yum Source).

Jiri, please, take a look.

I adapted the SourceImpl::enable function to call refresh if autorefresh().

I'm afraid refresh() does not implement the special behavior for CD vs. network sources.

With this refresh() on I don't see any objects any more from any kind of source. To double-check this, I commented out that call to refresh():

===================================================================
--- source/SourceImpl.cc        (Revision 2392)
+++ source/SourceImpl.cc        (Arbeitskopie)
@@ -227,8 +227,10 @@

     void SourceImpl::enable()
     {
+#if 0
       if (autorefresh())
        refresh();
+#endif
       _enabled = true;
     }

Then I can see packages, patches, patterns and selections again on my installation sources.

Lukas, please, add to online_update.ycp a code to refresh all sources
that have autorefresh enabled by calling Pkg::SourceRefresh().

This is a temporary solution.

Fixed for yast online update

--- cut ---

- Refreshing all sources (with autorefresh enabled) before the
  online is started (#154990).
- yast2-online-update 2.13.15

--- cut ---

libzypp rev. 2919 disables autorefresh for non-remote sources.

Is this fixed/hacked around now and can we therefore downgrade the severity?

I think so.

Marking as enhancement for 10.2.

I think Duncan did a lot of work in this area lately.

*** Bug 175642 has been marked as a duplicate of this bug. ***

I have a question. The network can be down. And current zmd design wipes the catalog before calling parse-metadata. In this case you will end with a empty catalog.

Reading a source in zypp does not download anything unless cache does not exist
or you call store metadata to reread from the URL to the local cache.

zmd checks the network status AFAIK but we should whether this works in this case.

Ws should download to a temporary and only remove the files if the new ones can be downloaded.  I think this is the same that zmd does with yum services.

comment #23: zmd checks NetworkManager which does not really support Modem and ISDN connections.

I am implementing safe download for storeMetadata.
This means yum will download not to SourceManager-managed cache dir but to a tmpdir. In case of success it will be copied over. That means parse-metadata can call storemetadata safely.

Can we markt this bug now as fixed?

Bug 178334 is closed - coudl we mark as fixed?

yes. But it is not that bad, zypp does not do download if the source has not changed, and a failed refresh for any reason should result in the same data as before (after a completely unneeded parsing sadly).