June 2009 - openSUSE Software Management

[softwaremgmt] Listing patches with "zypper patches/list-patches"
by Jano Kupec 29 Jun '09

29 Jun '09

(In reply to comment #5 https://bugzilla.novell.com/show_bug.cgi?id=506860#c5) > Anyway, IMO zypper should not deal with individual patch > resolvables, but use Selectable and test for Selectable::isSatisfied > (this considers the latest version of the patch). Agreed, i'll do it. But it made me think abou the patch lists we show. Currently 'zypper patches' shows all versions (resolvables): $ zypper patches <cut> openSUSE 11.1 Updates │ xpdf │ 579 │ recommended │ Not Applicable openSUSE 11.1 Updates │ xpdf │ 793 │ security │ Not Applicable <cut> Shouldn't we show only the latest, esp. if the policy dictates (is it documented somewhere?) that newer patches obsolete the older ones? And i guess for 'zypper list-patches' it's only natural that only the latest version should be shown as well then. -- 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)---

2 5

[softwaremgmt] python/libzypp: query source repo of installed packages
by Elmar Stellnberger 18 Jun '09

18 Jun '09

wanna make a package stat - how many packages are currently installed from a given source: how can I * query for all installed packages * the source a package has been installed from via python Have found some doc about python/libzypp, but it does not tell me how to query for the package source of an inst. pkg (http://lizards.opensuse.org/2008/10/03/developing-with-libyuilibzypp-python…) Besides this I have found some promising C++ code which I however could not translate to python (methods/obj do not seem to exist in /usr/lib64/python2.6/site-packages/zypp.py): http://pastebin.com/m3d26a44 -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

3 17

[softwaremgmt] Feature - running program at end of the instalations/on configure files conflict
by Michal Hrusecky 15 Jun '09

15 Jun '09

Hi, I've been thinking about how to work with configuration files updates (feature #306411 [1]). In the end it seems that it would require some adjustments to installation system as well. I think it can be divided into two main features, so I'll post them here in two e-mails so it will be easier to track them. And the reason is of course to discuss there features, collect ideas and hopefully somebody will consider/implement them. Second thing that would be nice to have is some trigger which will get run after each installation/deinstallation/upgrade. Well, easiest way to implement feature #306411 is to use some script to collect conflicting configuration files after each installation and to display some warning that there are some conflicts that needs resolving. Warning should be easily possible to do, once previous feature would be supported. Other possibility how to achieve the same result would be some patch for rpm so it will generate such a message itself or calls something to "merge" conflicting files. I'm not sure what would be the best approach here. I can see some more generic usage of the first approach (like logging into mailbox or database), but I'm starting to think that second approach sounds better although patching rpm because of such a specific and probably minor feature also doesn't look like a good idea... [1] https://features.opensuse.org/306411 -- Michal Hrusecky Package Maintainer SUSE LINUX, s.r.o e-mail: mhrusecky(a)suse.cz

4 3

[softwaremgmt] Feature - notifications
by Michal Hrusecky 12 Jun '09

12 Jun '09

Hi, I've been thinking about how to work with configuration files updates (feature #306411 [1]). In the end it seems that it would require some adjustments to installation system as well. I think it can be divided into two main features, so I'll post them here in two e-mails so it will be easier to track them. And the reason is of course to discuss there features, collect ideas and hopefully somebody will consider/implement them. First thing that would be nice to have is some general notification feature during installation. It has been already discussed on zypp-devel mailing list [2]. I'll try to summarize what I think was mentioned in related thread. We need two (maybe more) types of notifications: - critical (user has to agree that he knows about it) - non-critical (user probably wants to know this but he can safely ignore it) What notification should contain: - condition (package name and package version, current and previous, other condition whether this notification should be displayed) - whether it was displayed and dismissed - notification itself One solution suggested somewhere was storing these notices as files with some special format somewhere in /var/adm. Other suggested thing was that these notices shouldn't be displayed during installation, but in the end and easy to skip so automatic installation would just store them and bug user about them next time he tries to install something. And user wouldn't need to click on something every five minutes. [1] https://features.opensuse.org/306411 [2] http://lists.opensuse.org/zypp-devel/2009-05/msg00001.html -- Michal Hrusecky Package Maintainer SUSE LINUX, s.r.o e-mail: mhrusecky(a)suse.cz

1 0

[softwaremgmt] obtain source repo directly via rpm header
by Elmar Stellnberger 07 Jun '09

07 Jun '09

What about simply utilizing a previously unused rpm-tag to directly determine via the rpm-header where a package came from? Then we do not need to parse the whole history just for this purpose! I have had a look at all header entries and have found a promising up to now unused candidate: RPMTAG_SOURCE For the future RPMTAG_SOURCE could carry the Buildservice-URL a package is provided via. SOURCE = http://download.opensuse.org/repositories/KDE:/Community/openSUSE_11.1 RPMTAG_DISTRIBUTION could then no longer be complicated with the info already present in RPMTAG_ARCH, but extended with a hint like Buildservice/Core: now: DISTRIBUTION = openSUSE 11.0 (X86-64) ARCH = x86_64 as proposed: DISTRIBUTION = openSUSE 11.0 / Buildservice ARCH = x86_64 .. then I can wrack my fresh history parser implementation; slurp. -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

5 13