Mailinglist Archive: opensuse (2831 mails)

< Previous Next >
Re: [opensuse] New drpmsync Version available
  • From: Robert Schiele <rschiele@xxxxxxxxxxxxxxx>
  • Date: Mon, 10 Jul 2006 16:02:00 +0200
  • Message-id: <20060710140200.GC19116@xxxxxxxxxxxxxxxxxx>
On Mon, Jul 10, 2006 at 03:19:48PM +0200, Michael Schroeder wrote:
> On Mon, Jul 10, 2006 at 03:01:41PM +0200, Robert Schiele wrote:
> > No, I don't need. If Novell insists in keeping all of the vital
> > infrastructure of the openSUSE project prorietary
> drpmsync isn't proprietary. Stop spreading nonsense.

I said vital infrastructure, not drpmsync in particular. And this is not
nonsense but a fact. The scripts for building the repository are proprietary
and those are the ones I considered best to put this into.

> > and you exploit that fact
> > refusing to keep the discussion on a senseful level by not providing arguments
> > for your opinions then I should most likely opt out at this point. In that
> > case every further minute I invest here seems to be a complete waste of time
> > and I should prefer investing that time in preparing my move to Vancouver.
> Sure, if that suits you better, go ahead.

Thanks for finally being open here. Now at least I have written consent that
it does not make any sense.

> > Whoever puts it there. It should be visible through traditional protocols like
> > rsync to support mirrors that do not run drpmsync _without_ the need to
> > contact a single point of failure server before.
> You didn't get my point: I said that arguing that drpmsync should put
> its filelist on disk is like saying that rsync should put its (i.e.
> rsync's) internal file list on the disk.
> The main problem with this is just that the data is outdated if
> there's an update just running, so you'll get a lot more errors
> about missing files than when the filelist is generated on the fly.

No. For the drpmsync server itself it is perfectly ok to create the list on
the fly. But there should be a static version available for
non-drpmsync-server systems. The argument that this might get out of sync
does not really match here because getting out of sync is ways better than
having no server at all.

Again: My proposal should not influence the way the drpmsync server operates
at all. I intends to provide an _alternative_ way of doing things without
doing any harm (but using about 3MB of disk space) to any other service. I
would even provide a patch for the repository building scripts to do so but
because they are prorietary (Yes, they are!) I cannot do this. And since
Novell neither gives support to include this feature there nor does it provide
any reason for not doing so, I will now follow your advice from above and
cancel this project until Novell changes their general attitude to this


Robert Schiele Tel.: +49-621-181-2214
Dipl.-Wirtsch.informatiker mailto:rschiele@xxxxxxxxxxxxxxx

"Quidquid latine dictum sit, altum sonatur."
< Previous Next >
Follow Ups