Mailinglist Archive: opensuse (3893 mails)

< Previous Next >
Re: [opensuse] SUSE repository
  • From: "Carlos E. R." <robin.listas@xxxxxxxxxxxxxx>
  • Date: Tue, 2 Jan 2007 17:57:07 +0100 (CET)
  • Message-id: <Pine.LNX.4.64.0701021738410.14877@xxxxxxxxxxxxxxxx>
Hash: SHA1

The Tuesday 2007-01-02 at 12:56 +0100, Pascal Bleser wrote:

> Carlos E. R. wrote:
> > The Tuesday 2007-01-02 at 11:12 +0100, Pascal Bleser wrote:
> >>>> Firing that module takes half an hour or more in my system (10.1).
> >>> Definitely get rid of ZMD on 10.1
> >>>
> >>>
> >
> > It doesn't explain there what removing ZMD would affect.
> Your system will work better. Less resource scamming because ZMD is gone
> and the zypp backend works better anyway.
> Using the ZMD backend involves syncing the repository metadata that is
> fetched by yast2 with the ZMD backend, for every repository.
> That means a lot of overhead as the metadata is most probably synced
> twice, which in turn is part of the reason the yast2 module takes half
> an hour or more to refresh repositories on your system.
> Even more so on 10.1.

The thing is, the paragraph (copied below) in the
<> link seemed to say to
remove ZMD and use smart instead of Yast - it doesn't say that Yast will
work fine or better without ZMD. Your explanation makes the thing clear,
but the wiki is not.

| Sources here can either be added using YaST, or by using the rug
| command-line tool, or thirdly by using the excellent Smart package
| manager. Since there were problems with ZMD (of which rug is the
| command-line tool) we recommend that you use the Smart Package Manager,
| instead of YaST and rug.

However, as I intend to update to 10.2 when I have some time, perhaps I
will refrain from removing zmd for the time being. I would prefer having a
toggle in yast to choose repo type, perhaps.

> Actually you can still use yast2 as your package manager on 10.1, just
> remove ZMD and the yast2 ZMD backend as explained on the wiki page, and
> yast2 will fall back to the zypp backend.
> That one works fine, uses less resources, doesn't involve syncing.
> You'll just lose the zen-updater applet for the systray.

That's fine, I never use that applet. I don't like it. If I had users, I
would remove it completely, I do not want users to be informed of things
that are not their business.

> On 10.2 there's the opensuse-updater applet when using the zypp backend.
> >>>> It could use an rsync method instead of full download of the metadata.
> >>> Most servers don't provide rsync but only HTTP and/or FTP.
> >>> And it wouldn't help much anyway because when the metadata is generated
> >>> again, all the metadata files are modified. RPM-MD metadata files are
> >>> even gzipped, so it's very unlikely rsync's binary deltas would be a big
> >>> help to reduce the download size.
> >
> > The repodata directory of packman contains about 2.5 MB for 10.2 and more
> > than double for 10.1; yours is about 2 Mb. That's very noticiable for a
> > modem. If than could be reduced somehow, it would be very nice. For a
> > modem that means... seven minutes download. For an adsl at 100KB/S it's
> > under a minute, not important compared to the half an hour it takes
> > processing or who knows what.
> Well, what can I say. If we could reduce it some way, we would have done
> it years ago. A magic spell won't reduce it from 2MB to 20kb.

I know, I know.... well, no, I don't, I met repos with 10.1, didn't know
it was years old. If I had designed it I would have something to say, but
as a bystander I can only grumble :-)


Yes, I remember having reading this before.


Yes, I read that one at the time. Nothing to object as it is.

I can only think of using rsync - but, as you say, not all or even many
servers allow it, so it is not viable - or splitting repodata into several
files, in the hope that some of them might not change. Dunno. I can only
grumble ;-)

- --
Carlos E. R.

Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Made with pgp4pine 1.76


To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >