Public SourceMage Discussion List

[Sukneet Basuta <sukneet AT gmail.com>]

On Mon, Feb 18, 2013 at 6:03 PM, David Kowis <dkowis AT shlrm.org> wrote:
> 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.

Do you have an example where
downloads.sourceforge.net/${PROJECT_NAME}/${SOURCE} doesn't work? I
have never come across one.

On Mon, Feb 18, 2013 at 6:07 PM, David Kowis <dkowis AT shlrm.org> wrote:
> There is no official mirror list that sf.net provides, and it's foolish
> to try to invent one where none exists.

http://sourceforge.net/apps/trac/sourceforge/wiki/Mirrors

On Mon, Feb 18, 2013 at 6:07 PM, David Kowis <dkowis AT shlrm.org> wrote:
> I can't speak for python, but the ruby gems (not sure about the ruby MRI
> sources) are handled via a load balancer. Generally, it's handled the
> same way we handle download.sourcemage.org, a load-balancer sends them
> to the appropriate mirror. Which, interestingly enough, is the same way
> sf.net is doing it. Which would indicate to me that it would not be a
> good idea to invent a mirroring scheme where none exists, at least for
> ruby gems.

My only issue with load balancers is that it is possible to be sent to
a mirror that is slow for you. Granted, that is unlikely to happen
with a proper load balancer and you will generally be sent a mirror
that is currently best for your location, but it does happen. That's
why I think it should be up to the user's choice.

Anyway, even if we do wish to have a mirroring system for sourceforge,
we will still have to change the links to their project specific URLs,
as David is stating to do, otherwise you will just be forwarded to
their load balancer.

On Sun, Feb 17, 2013 at 6:29 PM, David Kowis <dkowis AT shlrm.org> wrote:
> Well, two reasons.
>
> First: It's easier to just change the url in the spell files than it is
> to update sorcery, and override currently set local variables. I've
> discovered that if you have a local SOURCEFORGE_URL set (as in, you
> picked one in the menu) updating sorcery to remove that mirror from the
> list does nothing at all. It still uses the one you picked, even though
> it doesn't exist any more, because local settings aren't referencing
> anything in the mirror file, it's just a string.

Looks like you are correct. It should be possible to run sed or awk or
something on /etc/sorcery/local/url to make sure that the urls are
valid on updating the mirrors.

On a side note, I don't seem to have smgl-mirrors installed, which
will probably be the easiest way to update the mirrors. Shouldn't that
be part of basesystem?

> Second: There's no reason to pretend like we have a SOURCEFORGE_URL
> mirror system at all. If we want to keep a SOURCEFORGE_URL for reuse
> purposes, I'd stick it in the grimoire functions, and I might call it
> something different, or make it a function rather than a variable.
>
> sourceforge_url {
>  "http://download.sourceforge.net/$1";
> }
>
> would probably be sufficient to save on the typing, although it's not
> much typing anyway. I'd rather put the onus back on the spell, since
> there's no mirror system within sorcery, and I'd like to make a clean
> cut from it.

That seems fair to me. We use variables for urls that have mirrors and
the full url for links that do not.

However, even if we decided to stop using a variable for
SOURCEFORGE_URL, we should still fix the mirror list since it will
take some time to fix all the urls.

I still think the best thing to do is to set SOURCEFORGE_URL to
downloads.sourceforge.net. This will allow all spells to still work
and, if we wish, to slowly set the paths to project specific URLS.
That way, we can support a mirror system for sourceforge in the
future.