September 2007 - Zypp Development - openSUSE Mailing Lists

[zypp-devel] zypp backend in packagekit
by Justin Haygood 15 Oct '07

15 Oct '07

I already created a page up on opensuse.org for it: http://en.opensuse.org/PackageKit We probably should get someone to make some test RPMs of the minimum requirements first though: (these are hard requirements from Richard Hughes) dbus 1.1.2 (10.3 B3 has 1.1.0) PolicyKit 0.5 (10.3 B3 has 0.4) Once we get these in, we could probably start on a zypp backend. I've already done a little bit (of non-coding) research into what's required already. It'd be even better if we could get this in 10.3 final, but highly doubt it... Thanks, Justin Haygood BTW: I CC'ed a few people dmacvicar mentioned would be interested in assisting with this project. -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 6

[zypp-devel] How to Use libzypp Repositories Within Installation/Upgrade
by Lukas Ocilka 27 Sep '07

27 Sep '07

Hi, This is mostly about using current repositories during upgrade (using CD/DVD media) but also about migration of these sources. During the beta phase of 10.3 a new feature has been added: When upgrading to 10.3, a new dialog appears offering to use previously used repositories in the upgrade process. How does it work? * First, it tries to find sources in the /var/lib/zypp/db/sources/ directory. * If they are none, it tries /etc/zypp/repos.d/ * Then, if any sources are found, it offers them to be enabled during the installation. * Installation then creates either disabled or enabled sources according to the user's request and these sources are used in the upgrade process. * Later, installation stores all sources used during installation to the target disk. What's wrong? * When upgrading 10.2 to 10.3 everything is fine: - Sources are found in /var/lib/zypp/db/sources/ - They are added either enabled or disabled during upgrade - They are stored to the target to /etc/zypp/repos.d/ - libzypp works with /etc/zypp/repos.d/ correctly * When upgrading 10.3 to 11.0 a problem appears: - Sources are found in /var/lib/zypp/db/sources/ - They are added either enabled or disabled during upgrade - They are stored to the target to /etc/zypp/repos.d/ but as you expected, the old ones remain there. - In the end, there are old sources as they were before the upgrade and also the new ones as decided by user during the upgrade. Why such thing happens? Because installation proceeds in inst-sys with target mounted to /mnt. Libzypp doesn't use target's repositories (which is correct because of memory consumptions). Installation/Upgrade needs to select which sources should be used and why shouldn't (for instance old online update source). Solution? A very quick but very dirty hack would be to remove all sources from /etc/zypp/repos.d/ before storing the actual set of sources to the target. Is there any better solution? Could you, please, help me with it? See bug #326325 Thanks & Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

2 3

Re: [zypp-devel] Proposal for libzypp4
by Justin Haygood 26 Sep '07

26 Sep '07

>Dňa Tuesday 25 September 2007 16:53:42 Justin Haygood ste napísal: >> While updating to the latest factory packages last night, it dawned on >> me on how inefficient the download -> install package cycle goes, >> specially since my downstream bandwidth (3.0 Mbps) seemed to take little >> hit during the process (with 2 machines doing the updates actually!). >> >> Wouldn't it be more efficient to "split up" the process so to speak: >> >From a remote repository, once installation has started, there are 2 >> >> basic things going on: >> >> A. Downloading of packages from remote repository to local cache. >> B. Installation of packages from the local cache. >> >> The way I see it, B is dependent on A, but A is totally independent of >> anything else once the final package list is acquired. >> >> My proposal is as follows: >> >> 1. For any repo that copies files to a local cache before installation >> (I think its just remote repos, but they might be more?), downloading >> will happen in the background, downloading a configurable amount of >> packages simultaneously (2 would be a good default). If the remote >> repository is HTTP, it can use HTTP Keep-Alive to keep the download >> connection going. >> >> 2. The installation happens in the foreground. Once a package has been >> acquired, it can install the package. There might be a small delay while >> it waits on the package to be downloaded, but it'll be a smaller >> download if it has to wait for the full package to be downloaded, since >> the download started, in a worse case scenario, at the beginning of the >> installation of the previous package. This is better than current, since >> right now, downloading packages does not start until the previous >> package has finished downloading. >> >> Comments/Suggestions? > >This is on our radar as a possible improvement for the future. The reason for > >the current behavior is the 1st stage installation, where the space is really > >tight. > >I agree this is a bit non-optimal for a running system. > Even during first-stage installation, this could probably be used if there's enough resources available (for instance, a gig or more of RAM with plenty of swap). My laptop (Inspiron 6400 + Core Duo CPU + 2 GB RAM), even during first stage installation, has about 1.5 GB of free RAM + 2 GB swap available on average according to top. -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0

[zypp-devel] Proposal for libzypp4
by Justin Haygood 26 Sep '07

26 Sep '07

While updating to the latest factory packages last night, it dawned on me on how inefficient the download -> install package cycle goes, specially since my downstream bandwidth (3.0 Mbps) seemed to take little hit during the process (with 2 machines doing the updates actually!). Wouldn't it be more efficient to "split up" the process so to speak: >From a remote repository, once installation has started, there are 2 basic things going on: A. Downloading of packages from remote repository to local cache. B. Installation of packages from the local cache. The way I see it, B is dependent on A, but A is totally independent of anything else once the final package list is acquired. My proposal is as follows: 1. For any repo that copies files to a local cache before installation (I think its just remote repos, but they might be more?), downloading will happen in the background, downloading a configurable amount of packages simultaneously (2 would be a good default). If the remote repository is HTTP, it can use HTTP Keep-Alive to keep the download connection going. 2. The installation happens in the foreground. Once a package has been acquired, it can install the package. There might be a small delay while it waits on the package to be downloaded, but it'll be a smaller download if it has to wait for the full package to be downloaded, since the download started, in a worse case scenario, at the beginning of the installation of the previous package. This is better than current, since right now, downloading packages does not start until the previous package has finished downloading. Comments/Suggestions? -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 1

[zypp-devel] Branched openSUSE 10.3
by Martin Vidner 25 Sep '07

25 Sep '07

On Thu, Sep 20, 2007 at 03:23:12PM +0200, Lukas Ocilka wrote: > Hi, > > Despite the fact that most of us are still fixing openSUSE 10.3 bugs, > there are some commits that should go to the "after 10.3 only". > > Our proposal is to branch openSUSE 10.3 on Monday 24th after 18:00 (with > RC2 if possible)- Mvidner is a volunteer for doing that :) I have just created the 10.3 maintenance branches: For YaST, at r41075 http://svn.opensuse.org/svn/yast/branches/SuSE-Linux-10_3-Branch For Zypp, at r7353 http://svn.opensuse.org/svn/zypp/branches/SuSE-Linux-10_3-Branch So for 10.3 fixes, use the branch (and merge the changes to the trunk right away). I will update the branch descriptions in the wiki shortly. http://en.opensuse.org/YaST/Development/SVN_branches http://en.opensuse.org/Libzypp/Development_Branches -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 3

[zypp-devel] zypper in 10.2
by Arvin Schnell 24 Sep '07

24 Sep '07

Hi, just a question: Why are there many changes in the 10.2 repository for zypper that are not included in autobuild? Compare <somewhere>/zypp/branches/SuSE-Linux-10_2-Branch/zypper/package/zypper.changes with /work/SRC/old-versions/10.2/all/zypper/zypper.changes ciao Arvin -- Arvin Schnell, <aschnell(a)suse.de> Software Engineer, Research & Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

4 5

Re: [zypp-devel] repo alias vs. name
by Di Pe 21 Sep '07

21 Sep '07

Hi, I am showing zypper to quite a few scientists and developers these days. They all love it but most of them actually think at first that "name" is the primary key and alias is some sort of optional field. May be alias should be called 'id' or 'key' or something like that. Or 'alias' could be called 'name' and 'name' could be called 'description' or 'label' or 'caption' or 'info' or something like that. just my 2 cents dipe > ----- Original Message ----- > From: "Jan Kupec" <jkupec(a)suse.cz> > To: zypp-devel(a)opensuse.org > Subject: Re: [zypp-devel] repo alias vs. name > Date: Tue, 11 Sep 2007 11:04:59 +0200 > > > See also https://bugzilla.novell.com/show_bug.cgi?id=309041#c6 and the > following comments. > > Jan Kupec wrote: > > Hi, > > > > i would like to achieve a new agreement about repository alias and name > > usage. > > > > The *last agreement* is to *use alias internaly* by applications and > > *present name to the user* (see [1]). YaST now uses the URL as both the > > alias and the name by default and allows the user to change the name. > > But then you get a mess like this in zypper: > > > > $ zypper sl > > # | Enabled | Refresh | Type | Name > > > > | URI > > > > --+---------+---------+-------+-----------------------------------------------------------------------------------+---------------------------------------------------------------------------------- > > 1 | No | Yes | yast2 | > > http://download.opensuse.org/distribution/SL-Factory-non-oss/inst-source-ex… > > | > > http://download.opensuse.org/distribution/SL-Factory-non-oss/inst-source-ex… > > > > 2 | Yes | Yes | yast2 | stable > > > > | > > ftp://dist.suse.de/install/stable-x86 > > 3 | No | Yes | yast2 | > > http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/ > > > > | > > http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/ > > 4 | No | Yes | yast2 | > > http://download.opensuse.org/distribution/SL-OSS-factory-debug/inst-source-… > > | > > http://download.opensuse.org/distribution/SL-OSS-factory-debug/inst-source-… > > > > In addition, zypper uses alias to as argment in repo handling commands > > and options (ok, you can use repo number (after i reimplement it - > > soon), but then you need to use zypper repos/lr/sl to list them each time). > > > > Another thing is, that libzypp names the .repo files in > > /etc/zypp/repos.d according to the alias, which again creates a mess if > > urls are used. > > > > My *proposal* is to use *alias as a short name* and the *name as a long > > name*. I.e., to use a user specified *short name/alias* as both alias > > and name by default, and leave the possibility to change the long name > > later (if not specified when ading the repo). > > > > IMO, this way, the overall user experience (mainly for zypper users but > > also for YaST users) will increase. > > > > If you don't like this idea for some reasons (e.g. the YaST users will > > need to enter the alias in addition to the URL, although they might like > > it :O), please, at least let's use something different internally in > > YaST for the alias, not the URL. Something shorter. > > > > [1] https://bugzilla.novell.com/show_bug.cgi?id=298035 > > > > Cheers, > > > > Jano > > -- > To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org > For additional commands, e-mail: zypp-devel+help(a)opensuse.org > -- We've Got Your Name @ www.mail.com!!! Get a FREE E-mail Account Today - Choose From 100+ Domains -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 3

[zypp-devel] issues using --non-interactive mode
by Di Pe 20 Sep '07

20 Sep '07

Hi, I just came across some issues using --non-interactive mode https://bugzilla.novell.com/show_bug.cgi?id=326651 may be there are some other workarounds that I missed? Dirk -- We've Got Your Name @ www.mail.com!!! Get a FREE E-mail Account Today - Choose From 100+ Domains -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 1

[zypp-devel] zypper and gcc 4.1
by Di Pe 20 Sep '07

20 Sep '07

Hi, zypper openSUSE:Factory/build service currently has this requirement in zypper.spec BuildRequires: gcc-c++ >= 4.2 However it compiles and runs just fine on opensuse 10.2 with gcc 4.1 Can you change the general requiment in openSUSE:Factory so we can easily link to this repository and create new zypper binaries for 10.2? BuildRequires: gcc-c++ >= 4.1 dipe -- We've Got Your Name @ www.mail.com!!! Get a FREE E-mail Account Today - Choose From 100+ Domains -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 1

[zypp-devel] arch problem
by Duncan Mac-Vicar Prett 17 Sep '07

17 Sep '07

I remember some bugzilla did reference a problem to update confusing arch with vendor? I had a similar problem today in my machine, git-core being seen as from another architecture. Problem: git-svn cannot be installed due to missing dependencies There are no installable providers of git-core == 1.5.3.1-3.1 for git-svn-1.5.3.1-3.1.i586[devel:tools:scm] === git-svn-1.5.3.1-3.1.i586[devel:tools:scm] === git-svn-1.5.3.1-3.1.i586[devel:tools:scm] will be installed by the user. subversion-1.4.4-19.i586 is needed by git-svn-1.5.3.1-3.1.i586 [devel:tools:scm] (subversion == 1.4.4-19) perl-base-5.8.8-72.i586 is needed by git-svn-1.5.3.1-3.1.i586 [devel:tools:scm] (/usr/bin/perl) git-svn-1.5.3.1-3.1.i586[devel:tools:scm] is needed by git-1.5.3.1-3.1.i586[devel:tools:scm] (git-svn == 1.5.3.1-3.1) git-core-1.5.3.1-3.1.i586[devel:tools:scm] provides git-core == 1.5.3.1-3.1, but has another architecture. perl-Error-0.17009-4.1.i586[devel:tools:scm] is needed by git-svn-1.5.3.1-3.1.i586[devel:tools:scm] (perl-Error >= 0.15009) You see nobody provides git-core for gt-svn, but my installed git-core is rpm -q --queryformat "%{ARCH}\n" git-core i586 which is exactly the architecture of: git-core-1.5.3.1-3.1.i586[devel:tools:scm] provides git-core == 1.5.3.1-3.1, but has another architecture. Anyone remembers the bug # ? Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 1

[zypp-devel] Question Regarding Packages with EULAs
by Justin Haygood 12 Sep '07

12 Sep '07

Hello. I'm investigating adding a zypp backend to packagekit, and during my investigation, I noticed that some packages zypp handles has EULA prompts. While discussing with Richard Hughes, we discussed how to handle this, and due to the backend design, there was 2 methods: 1. Showing the EULA before the package is queued (preferable) 2. Showing the EULA after the package is installed So basically.. the question for this list is: 1. Is the EULA for the package (such as flash-player, etc..) available before the package is installed, and available via the libzypp API? Thanks again for your time --Justin Haygood -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

4 4

[zypp-devel] repo alias vs. name
by Jan Kupec 11 Sep '07

11 Sep '07

Hi, i would like to achieve a new agreement about repository alias and name usage. The *last agreement* is to *use alias internaly* by applications and *present name to the user* (see [1]). YaST now uses the URL as both the alias and the name by default and allows the user to change the name. But then you get a mess like this in zypper: $ zypper sl # | Enabled | Refresh | Type | Name | URI --+---------+---------+-------+-----------------------------------------------------------------------------------+---------------------------------------------------------------------------------- 1 | No | Yes | yast2 | http://download.opensuse.org/distribution/SL-Factory-non-oss/inst-source-ex… | http://download.opensuse.org/distribution/SL-Factory-non-oss/inst-source-ex… 2 | Yes | Yes | yast2 | stable | ftp://dist.suse.de/install/stable-x86 3 | No | Yes | yast2 | http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/ | http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/ 4 | No | Yes | yast2 | http://download.opensuse.org/distribution/SL-OSS-factory-debug/inst-source-… | http://download.opensuse.org/distribution/SL-OSS-factory-debug/inst-source-… In addition, zypper uses alias to as argment in repo handling commands and options (ok, you can use repo number (after i reimplement it - soon), but then you need to use zypper repos/lr/sl to list them each time). Another thing is, that libzypp names the .repo files in /etc/zypp/repos.d according to the alias, which again creates a mess if urls are used. My *proposal* is to use *alias as a short name* and the *name as a long name*. I.e., to use a user specified *short name/alias* as both alias and name by default, and leave the possibility to change the long name later (if not specified when ading the repo). IMO, this way, the overall user experience (mainly for zypper users but also for YaST users) will increase. If you don't like this idea for some reasons (e.g. the YaST users will need to enter the alias in addition to the URL, although they might like it :O), please, at least let's use something different internally in YaST for the alias, not the URL. Something shorter. [1] https://bugzilla.novell.com/show_bug.cgi?id=298035 Cheers, Jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 2

[zypp-devel] zypp.conf
by Martin Vidner 07 Sep '07

07 Sep '07

I just thought I would set the refresh delay to 8 hours on my machine so I needed to edit the config file... please use this one as a stub. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu

4 3

[zypp-devel] [Fwd: Re: Updating vendors]
by Stefan Schubert 04 Sep '07

04 Sep '07

-------- Original-Nachricht -------- Betreff: Re: Updating vendors Datum: Tue, 4 Sep 2007 11:50:54 +0200 Von: Stephan Kulow <coolo(a)suse.de> An: Stefan Schubert <schubi(a)suse.de> CC: zypp-devel(a)opensuse.org Referenzen: <46DBC38F.4050106(a)suse.de> Am Montag 03 September 2007 schrieb Stefan Schubert: > Hi, > should we realy not upgrade these vendors: > > Discarding 'U__s_[S1:1][package]kdenetwork3-news-3.5.7-46.i586' from > vendor 'SUSE LINUX Products GmbH, Nuernberg, Germany' different to > uninstalled 'openSUSE Build Service' vendor. > Discarding 'U__s_@[S1:1][package]dvd+rw-tools-7.0-43.i586' from vendor > 'SUSE LINUX Products GmbH, Nuernberg, Germany' different to uninstalled > 'suse' vendor. > Discarding 'U__s_@[S1:1][package]agrep-0.7.5-31.i586' from vendor 'SUSE > LINUX Products GmbH, Nuernberg, Germany' different to uninstalled 'SuSE > Linux AG, Nuernberg, Germany' vendor. These 3 should definitely be compatible. Vendor strings starting with suse or opensuse should be considered ours. Any side effects of that should be discarded :) > > Additional there are "empty" vendors which will not be upgraded too: > Discarding 'U__s_@[S2:0][pattern]non_oss-10.3-118.i586' from vendor > 'SUSE LINUX Products GmbH, Nuernberg, Germany' different to uninstalled > '' vendor. This looks like a libzypp bug. Patterns do not have a vendor on its own, but should get the vendor of the repository they are from. > Discarding 'U__s_@[S1:1][package]libdv-1.0.0-6.i586' from vendor 'SUSE > LINUX Products GmbH, Nuernberg, Germany' different to uninstalled '' > vendor. This looks like a bug - I would think empty vendors are incompatible in itself. > > I think it is a little bit to much restricted. Any opinions ? See above. Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi(a)suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 1

[zypp-devel] Updating vendors
by Stefan Schubert 04 Sep '07

04 Sep '07

Hi, should we realy not upgrade these vendors: Discarding 'U__s_[S1:1][package]kdenetwork3-news-3.5.7-46.i586' from vendor 'SUSE LINUX Products GmbH, Nuernberg, Germany' different to uninstalled 'openSUSE Build Service' vendor. Discarding 'U__s_@[S1:1][package]dvd+rw-tools-7.0-43.i586' from vendor 'SUSE LINUX Products GmbH, Nuernberg, Germany' different to uninstalled 'suse' vendor. Discarding 'U__s_@[S1:1][package]agrep-0.7.5-31.i586' from vendor 'SUSE LINUX Products GmbH, Nuernberg, Germany' different to uninstalled 'SuSE Linux AG, Nuernberg, Germany' vendor. Additional there are "empty" vendors which will not be upgraded too: Discarding 'U__s_@[S2:0][pattern]non_oss-10.3-118.i586' from vendor 'SUSE LINUX Products GmbH, Nuernberg, Germany' different to uninstalled '' vendor. Discarding 'U__s_@[S1:1][package]libdv-1.0.0-6.i586' from vendor 'SUSE LINUX Products GmbH, Nuernberg, Germany' different to uninstalled '' vendor. I think it is a little bit to much restricted. Any opinions ? Greetings Stefan -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi(a)suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 2

[zypp-devel] Re: [zypp-commit] r7068 - in /trunk/libzypp: devel/devel.ma/Parse.cc zypp/ZConfig.cc zypp/ZConfig.h
by Stanislav Visnovsky 03 Sep '07

03 Sep '07

Hi! Maybe it's time to introduce 'man zypp.conf' or at least a fully commented zypp.conf example. Without this, the configuration features will get lost. Stano Dňa Friday 31 August 2007 21:41:15 mlandres(a)svn.opensuse.org ste napísal: > Author: mlandres > Date: Fri Aug 31 21:41:15 2007 > New Revision: 7068 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=7068&view=rev > Log: > Added "bool ZConfig::download_use_patchrpm()" > and "bool ZConfig::download_use_deltarpm()" > and corresponding zypp.conf entries: > [main] > download.use_patchrpm = true > download.use_deltarpm = true > > Modified: > trunk/libzypp/devel/devel.ma/Parse.cc > trunk/libzypp/zypp/ZConfig.cc > trunk/libzypp/zypp/ZConfig.h -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 2