Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] SOURCEFORGE_URL

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Remko van der Vossen <wich AT yuugen.jp>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] SOURCEFORGE_URL
  • Date: Tue, 19 Feb 2013 08:58:48 +0900

On Mon, Feb 18, 2013 at 05:03:19PM -0600, David Kowis wrote:
> On 02/18/2013 10:14 AM, Ladislav Hagara wrote:
> >
> >> tl;dr : Don't use SOURCEFORGE_URL any longer, sourcforge.net has their
>
> >> own mirror system; make sure your urls start with
> >> http://downloads.sourceforge.net/; Fix spells as you come across them.
>
> >>
> >>
> >> So our SOURCEFORGE_URL mirror system is very broke :(
> >
> >
> > It is a part of sorcery, so it should be updated in sorcery for all
> > users or get out from there.
> > Seems works for me.
> > If we really can't address official mirrors (I didn't test them) then
> > SOURCEFORGE_URL should be set to http://downloads.sourceforge.net/ and
> > $SOURCEFORGE_URL/$SPELL/$SOURCE will works like a charm.
> > Personally I would't changed DETAILS files by scripts. Don't touch
> > running system.
> > If Source Forge change it back again we will be prepared. :-)
> > And according to local variables, sorcery should warn users that it is
> > stale.
>
>
> Well, you're welcome to go make the modifications to sorcery to do
> staleness detection, it's not in there now.
>
>
> The SOURCEFORGE_URL pattern you described doesn't always work in all
> cases, leaving us where we're at right now. It's much simpler and more
> reliable to use the project specific URLs and let sourceforge handle
> their mirroring system.

+1

Why should we go and invest extra effort to keep a non-existent mirror
list maintained. sourceforge changed to a geo based load balancing
system and I don't see them changing back to some kind of mirror system
soon. The backward cmpatible urls they provide now are I think only for
the old released files, as now the projects can have a tree like
structure with possibly different files with the same name in different
locations in the tree, making the old way to fetch these files ambigous.
Also, I don't see them changing the current url schemes for the projects
anytime soon, if anything I would expect the backward compatible urls to
be dropped sooner than the current url scheme would be changed. In the
end the less stuff we have to maintain the better, we're already
stretched thin as it is...

And we don't have to do some mass migration from $SOURCEFORGE_URL to the
new url scheme unless we want to. As has been said, if you use a working
mirror the old way of adressing files works for most packages, but not
for all, so we can just fix the urls as we come across them, usually
probably together with version bumps or such, as that is when I would
expect breakage.

There is however the problem that some mirrors are completely gone, and
if you have selected such a mirror in sorcery nothing will work, same
holds for kernel and gnu mirrors by the way. For this I think the only
sensible way is a pragmatic solution; simply tell people to check which
mirrors they have selected and ask them to change if necessary. Why?
Because no change in sorcery mirror lists will solve the problem, only
dirty hardcoding of mirrors, or special update scripts that will modify
the users config will handle that. The only clean way to fix it is to do
a mass spell rewrite which has already been stated as undesirable and I
somewhat agree with that. For a mass spell rewrite it is simply a matter
of pros vs cons as far as I am concerned and I feel that this situation
does not need a mass spell rewrite, we can just change spells as they
break and/or are upgraded.

We simply need to agree on a way forward, what do we want sourceforge
based spells to look like? My vote is use straight urls and not
SOURCEFORGE_URL. When we have decided what we want we can just let it
migrate naturally by spell updates. (Like we remove UPDATED entries from
DETAILS for instance)

Regards, Remko




Archive powered by MHonArc 2.6.24.

Top of Page