July 2007 - openSUSE Software Management

[softwaremgmt] MetaPackage schema
by Adrian Schröter 25 Jul '07

25 Jul '07

Hi Benji, Michael and me looked at the new meta data schema and we had the following observations: We understand that you want to produce one working ymp file for all distros. This does mean that you need to maintain the definition for base repos also in yast, so that YaST does know what base distro is running. So you have a mapping rule in yast-metapackage-handler to map the strings from the ymp file to strings from install.inf or /etc/SUSE-release ? This does mean you will popup an error or warning popup when someone tries to add a repo for a not matching base repo ? Is it still possible to install openSUSE 10.1 repos on SLE-10 for example ? Michael and me think that the "<products>" and "<product>" tags could get a different name, because we associate it with something like "openSUSE 10.2" but not with a single package or pattern. What about "<software>" and "<rpm>" for example ? bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian(a)suse.de -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

2 3

[softwaremgmt] Re: possible ymp file changes
by Adrian Schröter 25 Jul '07

25 Jul '07

On Wednesday 25 July 2007 00:37:03 wrote Benji Weber: > On 24/07/07, Adrian Schröter <adrian(a)suse.de> wrote: > > Hi Benji, Martin, > > > > Slight offtopic, but we have the first auto generated ymp file in the OBS > > :) > > > > http://download.opensuse.org/repositories/KDE:/KDE4/openSUSE_10.2/ > > > > Feel free to try, review and complain about it :) > > Looks like it's based on the old schema, not the new one we were > discussing at http://en.opensuse.org/Standards/One_Click_Install Ups ... is this new format already supported by yast ? When will it be supported ? > If you could amend the schema at the above link with the additions you > made for the description etc, and modify your build service YMPs to > comply it would help me a lot. > > > Benji, is the icon okay or should we use a different one ? > > I think it make sense to use the same icon for ymp's everywhere ... > > I guess this is a question for the artwork/branding people. > > Would it not be sensible to move further discussion to one of the > mailing lists, opensuse-softwaremgmt or -project perhaps. yet another list to subscribe ;) But yes, your are 100% right ... bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian(a)suse.de -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

1 0

[softwaremgmt] when to refresh?
by Duncan Mac-Vicar Prett 20 Jul '07

20 Jul '07

Hi guys. If you read already the news on package management, there are some open issues we would like to have feedback from you. As you may know, now all operations on repositories are splitted, so you can add a repository without downloading metadata. But at some point to operate on them you need valid metadata and a binary cache. An example: zypper sa http://foo bar zypper search moo zypper install cuack for the search, you need cache, for the cache you need metadata. Should ZYpper exit and tell the user to refresh, or should it ask the user whether to refresh without exiting? In the case of YaST, should it download and refresh when adding the repos in inst_source, or should it do it during startup of the package selector? -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg 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

6 10

[softwaremgmt] package management in next alpha/10.3
by Duncan Mac-Vicar Prett 19 Jul '07

19 Jul '07

Hi community, The next alpha6 of openSUSE 10.3 will contain lot of changes in the package management code. I will try to summarize what is new so you can help us testing. The integration can bring some regressions, so please test it and help us to fix the remaining bugs during the betas. What were the goals: * no more refresh and parsing during startup. * more compatibility with tools like yum and smart * more speed for the common use case: install a package Before ZYpp did not make difference between launching the sources and refreshing them. This was quite annoying, and turned into needing network access for any operation requiring launching the sources first, like deleting, adding, searching. How does it work now? * Repositories now have a unique (in your system) alias. * Adding a repository is just a matter of copying [a .repo file ][1] (like those provided by the build service) to /etc/zypp/repos.d directory. If you use zypper or YaST it will create them for you, and perform additional checks. * Download of metadata happens during refresh. Also in this operation a binary cache is created. * deleting a repository is just a matter of deleting its .repo file, or doing it via zypper/YaST (they take additional checks like vacuum the cache). * YaST was just adapted and is still WIP, so in some places the old semantics could be still used (like refreshing repos even if it is not needed). * The binary cache allow to start up zypper and install packages in a much faster way. Caching the metadata is slow. But you do it once per refresh, and the data is stored preparsed in the cache. This allows to launch small repos in fraction of a second, and big repos in seconds later. No more parsing files in each startup. * Before lot of memory was used because most of the GUI data (descriptions, etc) was read into memory. Now all attributes (except resolvable information, for which we need indexes) is loaded on demand from the cache. * refresh operation uses now much less memory. One one object is kept in memory at time while writing the cache. For the developers: * Lot of testcases. We can do more aggressive development without breaking basic stuff. * Lot of redesign, to be able to implement new features. * We build with cmake now You expect for the future (post 10.3): * Integrate search with the cache, so no need to launch the resolvables and loop for searching * solving some queries from the cache? [1]: http://en.opensuse.org/Standards/RepoInfo -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg 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

[softwaremgmt] zypper from SLES10SP1 for 10.1?
by Andreas Vetter 19 Jul '07

19 Jul '07

Hi, I'm not sure if this is the right list, but ... In SLES10SP1 there is finally zypper. Is it planned to bring this version to 10.1? I mean as an optional package via normal YOU mechanism - no additional repository. This would be great, since one could get rid of zmd in 10.1, too. Thanks. -- Andreas Vetter Fakultaet fuer Physik und Astronomie Universitaet Wuerzburg -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

3 4

[softwaremgmt] using zypper in automated processes
by Jan Kupec 19 Jul '07

19 Jul '07

Hi there, zypper should now (version 0.8.3+) finally be ready for use in automated processes by providing several new options: --non-interactive global option - when using this option it is guaranteed that zypper will not hang prompting for an answer on stdin, or in an endless loop. Zypper will automatically answer the questions with default answers, influenced by some other options --no-gpg-checks global option - always choose to continue if some of the gpg checks fails, e.g. a repository file is not signed and should be, file is signed and gpg check fails, etc. --auto-agree-with-licenses special option for install and update commands. By using this, user declares he/she agrees with terms of licenses the command will install, and zypper will automatically say yes to license confirmation prompt. This is useful for people installing the same set of packages on multiple machines (by an automated process) and have read all the licenses before. LIST OF PROMPTS: The following should be a complete list of cases where zypper needs user interaction together with the answers in non-interactive mode. All the additional options mentioned here have higher priority over --non-interactive, so if used, the answer the imply are automatically used even if --non-interactive isn't used. gpg callbacks: where --no-gpg-checks is applied, a message is displayed or a warning is written to stderr and logged. - accept unsigned file? default: N, with --no-gpg-checks: Y - import key into keyring? always: N (new key can be imported only in interactive mode) - accept unknown key? default: N, with --no-gpg-checks: Y - trust key? default: N, with --no-gpg-checks: Y - verification of signed file failed, continue? default: N, with --no-gpg-checks: Y - no digest for a file, continue? default: N, with --no-gpg-checks: Y - accept unknown digest? default: N, with --no-gpg-checks: Y - accept wrong digest? default: N, with --no-gpg-checks: Y other prompts: - proceed with installation/removal/update? always: Y in addition, the --no-confirm option can be used with the above commands, even without global --non-interactive - confirm 3rd party license default: N, with --auto-agree-with-licenses: Y in addition, for zypper update, --skip-interactive option can be used to exclude interactive patches from to-be-installed list (heritage of rug) - problem while installing/removing a resolvable, Abort/Retry/Ignore? always: ABORT (this is ugly and can be improved in future) - problem while downloading a package, Abort/Retry/Ignore? always: ABORT (this is also ugly, can be enhanced somehow in the future) - dependency conflict. Prompt for solution number, (c)ancel, or (r)etry always: c Also, several different exit codes listed in zypper's manual page can be checked for when using zypper in an automated process. Feedback is welcome, as well as bug reports. I will also wikify this, after some time. Cheers, Jano -- Jan Kupec, YaST team member -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

3 4

[softwaremgmt] Signed repositories and replay attacks
by Christian Boltz 18 Jul '07

18 Jul '07

Hello, (CC to Marcus in case he's not subscribed here - he pointed out this issue some time ago) Since SUSE Linux 10.1, the repo metadata is GPG-signed so that nobody can inject evil packages (like glibc from 9.1, which is a well-signed package from SUSE ;-) There's still a hole left: It's impossible to check for replay attacks where an attacker provides an outdated version of the update repository, leaving some security holes unfixed. (Or there's just an outdated mirror, same effect...) IMHO this could be solved by adding an expiration date to the repos. The distribution repos could have a TTL of two years, the update repos and Factory maybe one or two weeks. YaST and other tools could then warn the user if "outdated" repos are used. Pros: - replay attacks with outdated update repos are impossible (at least if "outdated" means longer than some days) - outdated mirrors can be identified quickly (the users will complain ;-) - the end of lifetime of a distribution could be "announced" this way - users will instantly notice if their computer's date setting is wrong ;-)) Cons: - there's still a small timeframe between release of the fix and the expiration of the previous update repo version - if no updates are released for some days, you'll have to change the expiration date What do you think about this idea? Regards, Christian Boltz -- > Ist das sone Art wie cat sigdatei | grep suchstring? Oh nein - nicht schon wieder! Hilfeeee, Doktor! Ich sehe schon wieder so einen unnötigen cat ;-) [> Michael Raab und Jan Trippler in suse-linux] -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

2 1

[softwaremgmt] Problem with factory: repo changes extremely quickly
by Jan Kupec 12 Jul '07

12 Jul '07

Edith Parzefall wrote: > Meeting Minutes YaST Nbg. 2007-06-19 > ------------------------------------ > problem with factory: repo changes extremely quickly > even during update to factory, the meta data are already changing again. > Talk to autobuild team what can be done to get a consistent state for the > update. > In the running system: download all packages before installing. > During first install: server could keep older package versions a couple > hours. In fact, debian repos live like this (at least as far as my experience goes, not sure about it). That may be due to the very same fact, that they change quickly (testing, sid repos). Then, it is often possible to install packages even if the metadata are out-of-date, without running apt-get update first. Only after the package which is referenced by the out-of-date metadata gets removed, you are forced to update them. Keeping a few old versions for some time also allows to downgrade to some of previous versions very conveniently, e.g. in case the new package is too buggy to work with (which can easily happen with repos like factory or debian sid). Jano -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

1 0