Duncan Mac-Vicar wrote:

On Wednesday 20 June 2007 17:56, Jiri Srain wrote:

...

Hi!

This is my suggestion on how to define the refresh policy with refactored ZYPP:

We need to keep the information when last a source was refreshed in order to decide whether a source needs to be refreshed or not. In addition, we will need some policies defining whether a source should be refreshed or not.

RepoManager has a RepoStatus query with timestamp and checksum both for metadata and last cache build. I think I made them private.

As i suggested in other post to this thread, something like RepoManager::isUpToDate(RepoInfo) would be nice. Also what happens if network or particular repository is not available at refresh time? I believe it is solved by the fact that application is responsible for calling refresh on each known repo by itself and handle exceptions for each of the call by itself. So that in the above cases, it just catches exceptions prints a warning and continues with next repo, right?

...

2. Tools which should install a package. They should work as fast as possible. we can pay the price of installing package which already has an update at least in some cases.

This assumption is false in most cases. If the metadata is old then what will happen is that you will solve a old package that will probably match (because packages usually doesnt change dependencies often), but the link (filename) will be wrong and the package will fail.

This exposes a failure in metadata design, only updating the filenames will be a quite option for the use case you mention.

Your usecase works if the repo keeps the old version of the package as well (or more).

-- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On 20/06/07, Duncan Mac-Vicar wrote:

On Wednesday 20 June 2007 17:56, Jiri Srain wrote:

...

Hi!

This is my suggestion on how to define the refresh policy with refactored ZYPP:

We need to keep the information when last a source was refreshed in order to decide whether a source needs to be refreshed or not. In addition, we will need some policies defining whether a source should be refreshed or not.

RepoManager has a RepoStatus query with timestamp and checksum both for metadata and last cache build. I think I made them private.

...

2. Tools which should install a package. They should work as fast as possible. we can pay the price of installing package which already has an update at least in some cases.

This assumption is false in most cases. If the metadata is old then what will happen is that you will solve a old package that will probably match (because packages usually doesnt change dependencies often), but the link (filename) will be wrong and the package will fail.

This used to be a big problem back when YaST did not refresh automatically by default. People did not understand why their package installation was failing. Perhaps I'm missing something here, if the metadata is out of date it needs to be updated or package installation will likely fail. Why is checking on app start a problem? Bearing in mind that checking if the repository has changed will take a fraction of a second (My search trawler manages to check hundreds of repositories in a couple of seconds, most users will have maybe 10 subscribed). The reason for the slowness is not down to checking whether a repository has changed, it is down to updating the changed repositories. Particularly packman/guru often change one or two packages every hour, which requires a complete re-download of ~5mb. I see the resolution to this as metadata diffing, not assuming that the change doesn't affect the user. If the package manager is not checking on application start I think it certainly needs to check on download failure, as the most common reason for download failure would then be that the filename has changed. _ Benjamin Weber -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On 21/06/07, Jan Kupec wrote:

Checking is OK, displaying a warning that the repo you are using is out-of-date is a good thing. But automatically refreshing is another thing, see also the other branch of this thread.

Ok, I'd missed this subtlety, this makes sense. However, it might be worth either automatically refreshing or suggesting a refresh in the event of a 404 downloading a package _ Benjamin Weber -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

* Michael Andres [Jun 21. 2007 12:03]:

It works a s well, if commit first downloads all packages.

Which should be the default IMHO. At least verify the existance of the packages needed to commit the transaction. Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Dne čtvrtek 21 červen 2007 10:26 Jan Kupec napsal(a):

(Posting also to sw-management and yast, as this is (most of it) not zypp-specific. Please, discuss parts which are not zypp-specific on sw-management .)

Jiri Srain wrote:

...

Hi!

This is my suggestion on how to define the refresh policy with refactored ZYPP:

We need to keep the information when last a source was refreshed in order to decide whether a source needs to be refreshed or not. In addition, we will need some policies defining whether a source should be refreshed or not.

The basic refresh should be done by a cron job. However, there may be a reason not to do refresh via a cron job and do it only when SW management tool starts.

(if you don't have much time to read all this, skip to the IMPORTANT part below)

I personally don't like either of these ideas:

1) If doing refresh in cronjob, the user can get surprisingly stuck when trying to use zypp in the very moment when the repos are being refreshed. Also the huge download happens without user's supervision. However, we can offer the user to set up the cron job for him, but we cannot do it behind his back. Or he can set up a cron job by himself.

The cron job was not meant as a must. Of course it is user's choice whether to use it or not. If he has many repositories, user may find it comfortable to get al lmetadata refreshed over night and when installing software not having to wait until repos get refreshed. How is this solved in 10.2 when updater applet refreshes sources?

2) Please NOT when a SW management tool starts!! This is much more annoying than getting a "repository out-of-date" warning! Let's leave it to the user when he wants to refresh. E.g., often user just wants to quickly check whether a package is in the repository and doesn't need an up-to-date data. At least, ask him at the tool start-up, and only if the refresh is needed (current repomanager is able to check whether a refresh is needed, Duncan do we have a simple method for the check, or is it hidden in the code? something like RepoManager::isUpToDate(RepoInfo) would be nice).

That's the reason why I suggested two different policies depending on the kind of application. If your environment is not changing to oheavily or you keep old versions, you can rely on updates made by the updater applet or a cron job.

What i said above does not hold true for every SW management tool. For example, updater applets should always have up-to-date data (as Jiri says a few lines below).

IMPORTANT: always respect autorefresh setting!

...on the second thought... :O) We have this _autorefresh_ setting in .repo file which can be enabled/disabled for each repository separately by the user. If we respect this setting, then forget what i said above and i'll be fine with crons and on-start refreshing :O)

behavior clarification: - autorefresh disabled - refresh metadata ONLY ON USER REQUEST (e.g. zypper refresh, (new) Refresh button in YaST). - autorefresh enabled - application chooses when to refresh

Of course. If a source has autorefresh disabled or the source itself is disabled, it should never be automatically refreshed. Sorry for misisng this point.

We should just think about whether to enable or disable it by default.

Currently we do it depending on the kind of source (disable for CDs, enable for network sources). Jiri -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz