-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 PGNet wrote:

On Fri, Apr 3, 2009 at 8:04 AM, Duncan Mac-Vicar Prett wrote:

...

PGNet wrote:

...

is it possible to set up -- and then limit/filter -- a repo so as to only upgrade a single file, or subset of files?

e.g., atm i'd like to update to:

http://download.opensuse.org/update/11.1-test/rpm/x86_64/module-init-tools-3... zypper in module-init-tools ?

install upgrades if the package is installed and there is a new version of that package (you can see new packages with zypper lu )

heh, clearly i've mis-asked my question. "take 2" ...

yes, "zypper in" works. but that presumes that that repo has been added.

and, if it has, then "zypper up/dup" updates will pick up all _other_ files from that repo, too. no?

_that_ is what i'm trying to avoid ... i.e, i want _only_ repo-based updates of that ONE file from the repo.

In other words, you want to lock all the packages from that repo, except a few, so that the next time you run up (without arguments) or dup, it will upgrade only the few packages, right? What is your use case? This is what comes to my mind: i have 11.1 system with 11.1 repo + 11.1 updates. I want to have the newest git, so i add a factory repo, but i want only git (and it's deps, as needed) from it. I want to keep my system up to date with 'zypper up'. If the repo in question contains only packages that are not in other repos, then there's no problem - zypper up will only update _installed_ packages. The answer is no, this is currently not easily possible. The only thing that comes to my mind would be to create a script that would parse the output of 'zypper se -r your-repo', get the names of the packages and calle 'zypper al -r your-repo $packagename' on them. Then you would unlock the packages you _want_ to track using 'zypper rl $packagename'. But this would create a lock for each of the repo's packages that you do not wish to track, and that could mean a severe peformance penalty, depending on the number of the packages in the repo. Plus, you might have problems with dependencies of the packages (you would need to unlock them, too). Any other use cases? Is this worth looking into? Anybody has an idea how to do it? - -- cheers, jano Ján Kupec YaST team - ---------------------------------------------------------(PGP)--- Key ID: 637EE901 Fingerprint: 93B9 C79B 2D20 51C3 800B E09B 8048 46A6 637E E901 - ---------------------------------------------------------(IRC)--- Server: irc.freenode.net Nick: jniq Channels: #zypp #yast #suse #susecz - ---------------------------------------------------------(EOF)--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAknWMYEACgkQgEhGpmN+6QHcKwCfRDsL7a1uHxtfmWgHEj3D1u3/ CRQAoIiAfOO1XmvtDSph3aDVVwer8TYH =u9vS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

PGNet wrote:

On Fri, Apr 3, 2009 at 8:55 AM, Jan Kupec wrote:

...

In other words, you want to lock all the packages from that repo, except a few, so that the next time you run up (without arguments) or dup, it will upgrade only the few packages, right?

yes. as usual, better stated than i could. thanks.

...

What is your use case?

very specific example ...

i'm working on a bug where i need to track,

http://download.opensuse.org/repositories/Kernel:/SL111_BRANCH/openSUSE_11.1...

_that_ repo "got broke", adding a pesky, unresolvable dependency, e.g.,

"error: Failed dependencies: module-init-tools_fix_bnc480524 is needed by kernel-default ..."

with help from @suse folks, i find the workaround resolving pkgs @

http://download.opensuse.org/update/11.1-test/rpm/x86_64/?P=module-init*

now, _those_ pkgs i can, of course, manually "rpm -Uvh". works great. but, (for) now, i want to track updates @ both

repositories/Kernel:/SL111_BRANCH/openSUSE_11.1/ <--- ALL files in the repo update/11.1-test/rpm/x86_64/?P=module-init* <-- just the m-i-t pkgs, and NOTHING ELSE in the repo

not clear how that's done ...

...

This is what comes to my mind: i have 11.1 system with 11.1 repo + 11.1

(snip)

iiuc, yes. that's a similar example.

...

The answer is no, this is currently not easily possible.

rats.

...

The only thing that comes to my mind would be to create a script that

(snip)

understood. clumsy & inflexible, tho.

...

Any other use cases?

well, anytime/everytime that "solutions" to problems comes from multiple BuildService sources. and, as BS usage takes off, that's going to happen more frequently, not less, i'd guess ...

thanks.

"zypper up --force-resolution -r yourrepo module-ini*" is possibly what you are looking for? Regards Dave P -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On Friday 03 April 2009 17:55:45 Jan Kupec wrote:

PGNet wrote:

...

_that_ is what i'm trying to avoid ... i.e, i want _only_ repo-based updates of that ONE file from the repo.

In other words, you want to lock all the packages from that repo, except a few, so that the next time you run up (without arguments) or dup, it will upgrade only the few packages, right?

What is your use case?

This is what comes to my mind: i have 11.1 system with 11.1 repo + 11.1 updates. I want to have the newest git, so i add a factory repo, but i want only git (and it's deps, as needed) from it. I want to keep my system up to date with 'zypper up'.

If the repo in question contains only packages that are not in other repos, then there's no problem - zypper up will only update _installed_ packages.

The answer is no, this is currently not easily possible.

If the packages in that repo had a unique vendor, then one could add the repo with low priority. Explicitly install the packages from that repo. Then 'zypper up' will try to stay with that vendor. Right? ('zypper dup' will mess it up). If we'd need a solution the that works independently from the 'vendor', we could try to use the repos 'alias' as 'vendor'. - We'd need some repo attribute, so one can tell that the repo 'alias' should play the role of 'vendor'. - We'd need to find a way to easily determine the repo an installed package came from. - And finally some support from the solver, because certain installed packages will want to keep the 'repo' instead of the 'vendor'. -- 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 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Michael Schroeder wrote:

This is why the suggestion can't work. There is no way to find out where an installed package came from.

rpm -q --queryformat="%{DISTURL}" zypper obs://build.opensuse.org/zypp:Head/openSUSE_Factory/e395d196158db724d7f40fa6310f2fd1-zypper rpm -q --queryformat="%{DISTURL}" kde4-amarok obs://build.opensuse.org/openSUSE:Factory/standard/42ce80031cf6bdae22d04696fa188a3b-kde4-amarok

-- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

* Michael Schroeder [Apr 06. 2009 13:06]:

On Mon, Apr 06, 2009 at 12:50:06PM +0200, Duncan Mac-Vicar Prett wrote:

...

Michael Schroeder wrote:

...

This is why the suggestion can't work. There is no way to find out where an installed package came from.

...

rpm -q --queryformat="%{DISTURL}" zypper obs://build.opensuse.org/zypp:Head/openSUSE_Factory/e395d196158db724d7f40fa6310f2fd1-zypper rpm -q --queryformat="%{DISTURL}" kde4-amarok obs://build.opensuse.org/openSUSE:Factory/standard/42ce80031cf6bdae22d04696fa188a3b-kde4-amarok

Those strings don't identify repositories, they identify where the packages have been built.

Isn't that (combined with the package checksum) what counts in the end ? Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On Monday 06 April 2009 13:15:56 Klaus Kaempf wrote:

* Michael Schroeder [Apr 06. 2009 13:06]:

...

On Mon, Apr 06, 2009 at 12:50:06PM +0200, Duncan Mac-Vicar Prett wrote:

...

Michael Schroeder wrote:

...

This is why the suggestion can't work. There is no way to find out

where an installed package came from.

rpm -q --queryformat="%{DISTURL}" zypper

obs://build.opensuse.org/zypp:Head/openSUSE_Factory/e395d196158db724d7f 40fa6310f2fd1-zypper

...

rpm -q --queryformat="%{DISTURL}" kde4-amarok

obs://build.opensuse.org/openSUSE:Factory/standard/42ce80031cf6bdae22d0 4696fa188a3b-kde4-amarok

Those strings don't identify repositories, they identify where the packages have been built.

Isn't that (combined with the package checksum) what counts in the end ?

But it's limited to the buildservice. And in this case it may be easier to enforce creation of different vendor strings for the different buildservice repos. Then those obs repos would immediately be usable as low-prio repo. But vendor is not the best attribute to use for this, because it's not under control of the local user. It's a weak relation based on a convention the package builder has to follow. And some more assumptions, like 'no other repo uses the same vendor string too'. So if we really want to put effort into this, we should head for a 'installed package <> repo alias'. This is something the local user can controll. -- 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 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org