June 2007 - openSUSE Software Management

[softwaremgmt] Re: [zypp-devel] Source refresh policy
by Jan Kupec 21 Jun '07

21 Jun '07

(Posting also to sw-management and yast, as this is (most of it) not zypp-specific. Please, discuss parts which are not zypp-specific on sw-management <opensuse-softwaremgmt(a)opensuse.org>.) Jiri Srain wrote: > Hi! > > This is my suggestion on how to define the refresh policy with refactored > ZYPP: > > We need to keep the information when last a source was refreshed in order > to decide whether a source needs to be refreshed or not. In addition, we > will need some policies defining whether a source should be refreshed or > not. > The basic refresh should be done by a cron job. However, there may be > a reason not to do refresh via a cron job and do it only when SW management > tool starts. (if you don't have much time to read all this, skip to the IMPORTANT part below) I personally don't like either of these ideas: 1) If doing refresh in cronjob, the user can get surprisingly stuck when trying to use zypp in the very moment when the repos are being refreshed. Also the huge download happens without user's supervision. However, we can offer the user to set up the cron job for him, but we cannot do it behind his back. Or he can set up a cron job by himself. 2) Please NOT when a SW management tool starts!! This is much more annoying than getting a "repository out-of-date" warning! Let's leave it to the user when he wants to refresh. E.g., often user just wants to quickly check whether a package is in the repository and doesn't need an up-to-date data. At least, ask him at the tool start-up, and only if the refresh is needed (current repomanager is able to check whether a refresh is needed, Duncan do we have a simple method for the check, or is it hidden in the code? something like RepoManager::isUpToDate(RepoInfo) would be nice). What i said above does not hold true for every SW management tool. For example, updater applets should always have up-to-date data (as Jiri says a few lines below). IMPORTANT: always respect autorefresh setting! ...on the second thought... :O) We have this _autorefresh_ setting in .repo file which can be enabled/disabled for each repository separately by the user. If we respect this setting, then forget what i said above and i'll be fine with crons and on-start refreshing :O) behavior clarification: - autorefresh disabled - refresh metadata ONLY ON USER REQUEST (e.g. zypper refresh, (new) Refresh button in YaST). - autorefresh enabled - application chooses when to refresh We should just think about whether to enable or disable it by default. Example use case: for online update repo (small repo with patches) i'd use autorefresh enabled and let whatever app needs it to refresh it as it sees fit. But for factory i want to be in complete control when it will be refreshed (because of the amount of resources it takes - time, CPU, network), so i'd use autorefresh disabled. BTW: for cronjobs i'd recommend something like zypper refresh --respect-autorefresh (not implemented yet :O) because otherwise it would try to refresh all sources. (Also there will be zypper refresh --force to force refresh even if zypp indicates that it is not needed, but that's just by the way...) > There are two kinds of tools: > 1. Tools which take care of having the system up-to-date. They must always > work on as fresh metadata as possible > 2. Tools which should install a package. They should work as fast as possible. > we can pay the price of installing package which already has an update at > least in some cases. > > Therefore we need two different policies depending on the kind of source > (this is optional) and on the operation user performs (they can be set > to vehave the same of course). > > How often refresh is being performed via cron (if it is) can be read from > the cron configuration, I don't think we need to put this information to > any configuration file. > > In addition to cron, I suggest adding following variables (comments hopefully > explain their meaning) > > > --- snip --- > > # should the on-line update paplication (eg. YOU) consider doing a refresh > # or should it rely on a cron job? > ONLINE_UPDATE_AUTO_REFRESH="yes" > > # if the time since last refresh is higher than specified amount of time, > # the update tools refresh the source first > # if it is an update source (provided we have the tags); 0 means to refresh > # always when starting the on-line update tool > # filtering on-line update sources is questionable (consistency) > ONLINE_UPDATE_REFRESH_INTERVAL="1h" > > # should the desktop applet perform any refresh or just rely on cron job? > DESKTOP_APPLET_REFRESH="yes" > > # define how often the desktop applet should perform refresh. > DESKTOP_APPLET_REFRESH_INTERVAL="3h" > > # master switch for enabling or disabling auto refresh for software > # management tools (eg. 'yast -i', 'zypper') > # if disabled, refresh must be performed manually or via cron > INSTALLER_AUTO_REFRESH="yes" > > # auto refresh interval for tools primarily installing packages, not doing > # update; "0" means always when initializing source(s) > INSTALLER_AUTO_REFRESH_INTERVAL="24h" > > --- snap --- > > The above variables can be added to /etc/sysconfig/sw_management. > > The way time is specified can be discussed, I guess that the granularity of > hours or at most minutes is perfectly sufficient, however, we may support > any of fixed units or specifying the units with the value (as in examples > above). > Cheers, Jano -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

2 1

[softwaremgmt] [dank@kegel.com: [packaging] Quick usability test of app battery on Ubuntu]
by Klaus Kaempf 18 Jun '07

18 Jun '07

This might be interesting for a couple of people of this list. Klaus ----- Forwarded message from Dan Kegel <dank(a)kegel.com> ----- Date: Mon, 18 Jun 2007 01:56:46 -0700 From: Dan Kegel <dank(a)kegel.com> To: packaging(a)lists.freestandards.org Subject: [packaging] Quick usability test of app battery on Ubuntu Hi all, I missed the first part of the packaging discussion at DAM-4, but attended the tail end. The notes from the discussion are online at http://www.linux-foundation.org/en/Dam-4_breakout_packaging There was talk about the LSB App Battery at the meeting, so I decided to see if the average Ubuntu user could easily install and use those LSB-packaged apps. http://www.linux-foundation.org/appbat is the home page for the app battery. For x86, it directs the user to http://ftp.freestandards.org/pub/lsb/app-battery/released/ia32/ which is a raw list of downloadable packages, e.g. http://ftp.freestandards.org/pub/lsb/app-battery/released/ia32/lsb-xpaint_2… Clicking on that link on my Ubuntu Feisty system did in fact download and install the package with very little fuss, and the app does run. Yay! There were some hitches in the user experience, though. Here's a (fairly picky) list; don't worry if some of these are unreasonable. 0. The user has to know where to go to download the app battery. Ideally the apps in the app battery should show up in Feisty's "Add/Remove Software" program, where users normally go to look for software. 1. When I ran Feisty's "Add/Remove Software" program, and asked it to show me all installed software, lsb-xpaint didn't show up! (Is that list solely driven by repositories somehow?) 2. The app did not integrate into my system menus. It really should, shouldn't it? Even though this would require a minor violation of the /opt rule, I think it's worth it. We certainly do this for Picasa. 3. The app did not show up on my default path (and indeed, feisty has its own xpaint, so there's a minor clash). I suspect we should call the binary lsb-xpaint, and put a link to it in /usr/bin, even though that violates the /opt rule (again, we do this for Picasa, otherwise users will hate us). 4. If the package lsb-core is not installed, the lsb-xpaint package will happily install, but running /opt/lsb/appbat/bin/xpaint just says bash: /opt/lsb/appbat/bin/xpaint: No such file or directory Ideally the package would either have refused to install, or would have automatically triggered the install of lsb-core etc. (I don't recall if lsb-core is installed by default on Feisty. I suppose it is, but I don't know how to check. If it's not, that's a big black mark for usability.) In my copious spare time, perhaps I will look into addressing a few of these issues. - Dan _______________________________________________ packaging mailing list packaging(a)lists.freestandards.org http://lists.freestandards.org/mailman/listinfo/packaging ----- 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

[softwaremgmt] .repo files
by Duncan Mac-Vicar Prett 14 Jun '07

14 Jun '07

We are designing the new repo handling model of the SUSE package manager stack to be more compatible with YUM, smart and the build service .repo files. When I looked at the .repo files at the first time, I thought the baseurl= was a unique url, which was the url of the origin of the metadata (used to identify), and the actual urls were pulled from a mirror list. I was confused for a bit when I discovered a .repo can have more than one baseurl. Even more when saw the strange way to do multi-line in the ini file. That means basically, there is no url you can use to, in the case you add a .repo file which has a list of urls, but the same base url as an already existing .repo, just append the urls to the mirrorlist. Ok, that sucks (as much as the documentation). But now comes another problem. Our (broken) model, requires a pair (url, path). If we support more than one baseurl in the .repo file, you can't have path as a separate unique attribute. .repo files doesn't specifiy path. I think the best solution is to get rid of path completely. Do we need it? no. It is needed in CD, NFS only (probably ISO too?) because we are using it in a wrong way. Can aynone give examples? why is needed? I am sure we can destroy those examples using the standard Url structure (and abusing options) Duncan -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

5 6

[softwaremgmt] Unique attribute
by Duncan Mac-Vicar Prett 12 Jun '07

12 Jun '07

After discovering .repo files can have more than one base-url , that means we can't use the url as the identifier of a source, to build a run-time relation ship between the known sources list and the cached source in the database. As the .repo files force you to define a [section] alias per source, I think we should rely on each repo having a unique string id. Other attributes can be used as fallbacks, for example, if the alias is not supplied, the url can be used as an alias too. What do you think? -- 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

4 7

[softwaremgmt] YUM metadata design problems and missing info
by Jan Kupec 12 Jun '07

12 Jun '07

(posting also to zypp-devel, but pls. discuss it on opensuse-softwaremgmt) First of all, if anyone can point me to an existing documentation of YUM xml schemas WITH comments on semantics, please do so. What we have on opensuse.org [1] and libzypp svn [2] is not enough (i will extend the info with what i've learned so far ATP) and digging the code that actually uses the data doesn't allways help. Also, we should agree what should be an authoritative place for specifications. The bare schema (rnc|rng|dtd) files are good for validation, but not for exact specification and semantic docs. But if commented, it would make a difference. Or should [1] be used? I'd vote for comments inside RNCs with a link to them on wiki. Some unclear things: patch.rnc - xml:base + href (anyURI) seems like we ignore xml:base attribute of all location data (not only in patch.xmls) and use just href as a relative path to a file on source URL. What about stating it somewhere in docs explicitly and dropping xml:base from suse extensions completely. Or start to support xml:base. - update-script - what is it? is it a redundancy in addition to script atom? - license-to-confirm (see bellow) - rpm base attributes redundant? patchrpm and deltarpm elements both have attributes that seem not be used and redundant: - filename can be found in patchrpm/location[@href]? - downloadsize == patchrpm/size[@package]? - m5sum - isn't patchrpm/checksum enough? - buildtime == patchrpm/time[@build]? - size attributes - we use them as follows: - package - rpm file size - installed - installed size - sum of unpackged contents - archive - ? suse-primary.rnc - license-to-confirm { localized-string }* this has multiplicity zero-or-more, but there is no way to tell particular translations apart except to rely on tag order, which is (by definition) undefined. Either we add an identifier to the tag or we add <licenses> tag to encapsulate them (or we remove the multiplicity). Cheers, Jano [1] http://en.opensuse.org/Standards/Rpm_Metadata [2] http://svn.opensuse.org/svn/zypp/trunk/libzypp/zypp/parser/yum/schema -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

3 3

[softwaremgmt] rpm5.org
by Christian Morales Vega 11 Jun '07

11 Jun '07

Hi, I was just curious about what posture openSUSE has about RPM. We have the rpm.org vs rpm5.org battle, and RPM 5.0 promises "an integrated package dependency resolver" for "the second half of 2007". So, what that means for libzypp? -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

1 0

[softwaremgmt] MetaPackage schema
by Benji Weber 07 Jun '07

07 Jun '07

Greetings all, In the last few weeks I've had several suggestions for improving the Single click install using metapackages which require altering the original schema. I've put an updated proposed schema and sample instance at http://en.opensuse.org/Standards/One_Click_Install The updated requirements for the schema is: Use case - Allow the user to install package(s) from (a) repositor(y|ies) (he|she) may or may not have in (his|her) system repositories. Scope -In scope is automating the process of the package manager adding repositories and installing packages. - In scope is presenting the user with sufficient information to understand the automated process. - Out of scope is any package management details such as package dependencies. Requirements - Action must be triggered with a one click. - Should be possible to include trigger on web page - Should be possible to include trigger on physical media for ISVs - Security (user should confirm adding of sources) - Should be possible to override auto-detection of repository type. - Should be possible to include multiple mirrors - Should be possible to have multiple translations of strings. - Should be possible to have one button/file to click on to install the product(s) for any version of the distribution. - Files should not need to be very big (translations optional etc) so download time is negligible. If you can think of any more requirements please reply to this message. Please also have a look at the new schema/sample instance and reply if you can see any problems with it or have any other suggestions. Many thanks _ Benjamin Weber -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

1 0

[softwaremgmt] Re: [Rpm-metadata] tags in .repo files
by Duncan Mac-Vicar Prett 06 Jun '07

06 Jun '07

On Wednesday 06 June 2007 10:18:59 Paul Nasrat wrote: > You might want to look at modifyrepo and use that in conjunction with > your own schema for tags, see the yum security plugin from yum-utils cvs > and yum.update_md for an implementation of adding arbitrary metadata. > > Paul Ok, so you suggest we add our own resource type to repomd.xml as we do with patches.xml, patterns.xml and as RedHat does with updateinfo.xml. -- 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] Re: [Rpm-metadata] tags in .repo files
by Duncan Mac-Vicar Prett 06 Jun '07

06 Jun '07

On Tuesday 05 June 2007 19:24:09 Paul Nasrat wrote: > On Tue, 2007-06-05 at 15:34 +0200, Duncan Mac-Vicar Prett wrote: > > .repo = repo files > > > > a file with: > > > > [repoid] > > baseurl=http://... > > etc... > > > > I want to assign tags to that repo, like, "updates,kernel,cool,unstable" > > What actual problem are you trying to solve with this tagging? The openSUSE build service allows project owners and the community to tag repositories and packages via the web interface and the web api. The resulting repositories are dumped as rpm-md repositories. Package management UIs should be able to get this tags so they can be displayed. -- 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] Re: [Rpm-metadata] tags in .repo files
by Duncan Mac-Vicar Prett 05 Jun '07

05 Jun '07

.repo = repo files a file with: [repoid] baseurl=http://... etc... I want to assign tags to that repo, like, "updates,kernel,cool,unstable" -- 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] tags in .repo files
by Duncan Mac-Vicar Prett 05 Jun '07

05 Jun '07

Hi, is there any tag defined for .repo files for tags? Should this go in the .repo file used to add the repository, or do you think it belongs to the metadata itself (repomd.xml). In the second case, the tags would be refreshed together with a source refresh. Cheers, -- 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