Benji Weber wrote:

2009/1/13 Duncan Mac-Vicar Prett :

...

A solution worth to explore is to start using variables like $releasever in the .repo files.

So repos with 11.1 would automaitcally be 11.2 afterwards. Of course still there is the need to check that those repos are valid.

Another possibility would be on upgrade to check for a file in each repository that would provide the URI of the equivalent repository in the new distro version.

That would require to initialize the repository at first and then download an optional file from there, then delete the repository again and register a new one provided by that file. Which also means we would have to setup the network before all this.

This could allow the repository publisher to provide an upgrade path for their repository without being tied to a specific URI format, moving to alternative locations, consolodation of multiple repositories into one and so on.

Anyway, these ideas could be also used for a running system as well (zypper, YaST repositories, ...). Lukas

Martin Vidner wrote:

On Wed, Jan 14, 2009 at 01:15:12PM +0100, Lukas Ocilka wrote:

...

That would require to initialize the repository at first and then download an optional file from there, then delete the repository again and register a new one provided by that file.

Funny how simple things have become. I thought it would be as complicated as one HTTP GET :-(

HTTP::Get("myurl", Directory::tmpdir + "/myurl.out"); // (yast2-transfer)

Yes, this solution looks quite simple but the "myurl" might be a bit tricky if it is not a HTTP-based repository. NFS needs to be mounted first, CD/DVD too, what about Samba? (etc.) And additionally, the repository uses "URL" + "Product Path". Funny how simple things become complicated when you have a lot of possibilities and "exceptions" - that's why we use libzypp (sharing the code at one place) instead of installing packages using the plain RPM. Lukas

Martin Vidner napsal(a):

On Wed, Jan 14, 2009 at 01:53:29PM +0100, Lukas Ocilka wrote:

...

...

On Wed, Jan 14, 2009 at 01:15:12PM +0100, Lukas Ocilka wrote: [...] HTTP::Get("myurl", Directory::tmpdir + "/myurl.out"); // (yast2-transfer) Yes, this solution looks quite simple but the "myurl" might be a bit

Martin Vidner wrote: tricky if it is not a HTTP-based repository. NFS needs to be mounted first, CD/DVD too, what about Samba? (etc.) And additionally, the repository uses "URL" + "Product Path".

Duh, I forgot about that, you're right. So we just want an equivalent of the above Get that works with all Zypp media and does not require a repo set-up.

That should be possible using three Pkg:: commands: /* this adds a temporary repository in memory without metadata download/refresh */ integer tmp_repo = Pkg::RepositoryAdd($["enabled" : false, "autorefresh" : false, "base_urls" : [ "URL" ], "prod_dir" : "/") /* download optional repo_update.xml file */ /* it should be signed for security reasons */ string downloaded_file = Pkg::SourceProvideDigestedFile(tmp_repo, 1 /*the first medium*/, "repo_update.xml", true /* optional */) if (downloaded_file != nil) { /* process the repo update file here - update the URLs */ } /* clean up */ Pkg::SourceDelete(tmp_repo); -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Stanislav Visnovsky wrote:

Doesn't Fedora store the .repo file in a package, so updating a package updates the repo config?

Yes, I thought about that too - we have a special tag in .prod file but it (again) means we would have to update the .repo file (package) before running the upgrade from media. This means we would have to reinitialize the source and run a simple update (of product packages) on a running system first. * User boots the new installation media * Selects upgrade mode * YaST checks that the installed .prod files do not contain the update information * YaST recommends to reboot to the system and run (some kind of) online update * User does so and reboots back to installation media I don't like it much :) ;) L.

On Tuesday 13 January 2009 17:30:27 Duncan Mac-Vicar Prett wrote:

A solution worth to explore is to start using variables like $releasever in the .repo files.

So repos with 11.1 would automaitcally be 11.2 afterwards. Of course still there is the need to check that those repos are valid.

You know, the time between 'before' and 'afterwards' is the tricky part. Esp. upgrades in the running system will become more tricky, as the $releasever actually changes within commit (at the time the *-release package gets installed). But you need the new value before to get the new repos, and maybe you also want to keep the old repo for a while afterwards. Also a little damage to the release package, or a misplaced baseproduct symlink, and the repo you'd need to fix it is also unusable, because the systems $releasever was lost. I'd feel more comfortable if the variables played a less important role within the repo URL. If they'd serve as a placeholder, but can also define a fixed substitution value: ${releasever} - follow sytems releasever ${releasever:-11.1} - fixed 11.1 ${releasever:-11.2} - fixed 11.2 The fixed form is to ease rewriting the URL from some old to a new version. So you don't have to guess the location of a version part. And it could even be used in bash: $ echo ${releasever:-11.2} 11.2 And if we'd use ${releasever} in URL, then people will want to use it in alias and name as well: [repo-update-${releasever}] name=openSUSE-${releasever}-Update enabled=1 autorefresh=1 baseurl=http://download.opensuse.org/update/${releasever}/ But I'm not sure whether I like this. A classification of repositories which allows to make better decisions would IMO be the better approach. All the repos we add more or less automatically together with a product should be disabled(deleted) together with the product. Not rewritten, because the next product will probably provide it's own new set. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+