- 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

[softwaremgmt] rug complains about inactive dvd mount point
by Elmar Stellnberger 15 May '09

15 May '09

Having added the following service to zmd 4 | Inactive | ZYPP | Suse Linux 11.1 DVD | /media/dvd/ zen-updater always complains about the inactive dvd-repo not showing if any new updates are available. How can I stop actualization for the dvd-repo (mount dvd & service refresh: ok)? By the way is there any easy way to parse the history for zenworks as well? -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

4 9

[softwaremgmt] assign lower priority to newly added repositories
by Elmar Stellnberger 16 Apr '09

16 Apr '09

User added repositories should have a lower priority than the core distro repos (change request). Usually these repositories contain additional software not available anywhere else but are less trustworthy than the core distro packages. f.i. I do not want packages to be installed from Packman if they are available in the core distro as well. If there are certain packages that should rather be taken from Packman than OpenSuse-OSS I wanna select them manually. Even worse giving newly added repos a higher priority by default will make all those temporarily added repos that just were intended to install a single package or a few override the core distro packages. The security implications are really just too bad. So even if someone would like Packman to have a higher priority than the core distro packages that should not automatically be applied to all temporarily added repos. Even worse some users will desire to add Suse11.0-repos to a Suse 11.1 installation, because a couple of packages are not available in 11.1 as it is not a major release. -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

4 16

[softwaremgmt] elder suse distros
by Elmar Stellnberger 03 Apr '09

03 Apr '09

Where can I find elder versions of Opensuse? http://download.opensuse.org/distribution/ contains 10.2 as oldest distro, but I need 9.3. -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

2 1

[softwaremgmt] host elder opensuse distros
by Elmar Stellnberger 02 Apr '09

02 Apr '09

http://download.opensuse.org/distribution/ should host elder releases of OpenSuse then 10.0 i.e. 9.3, at best also 7.3, 8.1 A lot of legacy apps will not run or compile under newer versions. At worst f.i. my M3-compiler needs to bootstrap itself so that there needs to be a way to run binaries of 7.3 / 9.3. There is no way to do this with newer distros since the old binaries will segfault. It should not be a great deal to host elder Opensuse versions, should it? -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

1 0

[softwaremgmt] [jw+debian@jameswestby.net: Stable update procedures]
by Klaus Kaempf 30 Jan '09

30 Jan '09

This looks interesting, esp. in the light of recent discussions on 'live' upgrading. Klaus ----- Forwarded message from James Westby <jw+debian(a)jameswestby.net> ----- Date: Thu, 29 Jan 2009 23:50:08 +0000 From: James Westby <jw+debian(a)jameswestby.net> To: distributions <distributions(a)lists.freedesktop.org> Subject: Stable update procedures Hi all, I've just got round to reading this week's LWN and it has an interesting article entitled "Fedora looks to prevent upgrade disasters" http://lwn.net/Articles/316194/ It's subscriber-only for a week, if you can't see it then mail me privately for a subscriber-link, or better yet subscribe to LWN, it's worth it. I was actually thinking of sending this mail the other day, but the appearance of this article sealed it for me. I'm interested in the procedures that other distributions have for making changes to "stable" releases, whatever that means for you. I'm especially interested what parts you find work well, and what problems you find. I'm not particularly interested in the procedure for security updates, more for bug fixes/new versions, obviously except for the cases where the procedures are the same. What are the rules for what is allowed? What is the process for doing it? What QA is done on the updates? How are regressions caught? How are regressions handled? I expect there will be a large variance here, but I hope it can be instructive. I'll write a reply with the details for Ubuntu when I'm not supposed to the packing to leave the country in a few hours, unless someone else beats me to it. Thanks, James _______________________________________________ Distributions mailing list Distributions(a)lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/distributions ----- End forwarded message ----- --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

1 0