From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject:
 Re: [PATCH] Fix bug 10504: match download's sourceurl mangling in, updxlrator
Date: Sun, 07 Jan 2018 19:53:22 +0000
Message-ID: <1515354802.2627.1.camel@ipfire.org>
In-Reply-To: <e6cf5f63-00ae-fcf6-81ba-95c9fc4ea0af@mail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5456950253166541886=="
List-Id: <development.lists.ipfire.org>

--===============5456950253166541886==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hello,

I just merged all the patches into next so they are queued for Core
Update 118 now.

Please have a look that everything got applied correctly.

And of course please test :)

Best,
-Michael

On Sat, 2017-12-30 at 18:57 +0300, Justin Luth wrote:
> On 12/30/2017 05:27 PM, Michael Tremer wrote:
> > On Fri, 2017-12-29 at 17:12 +0300, Justin Luth wrote:
> > > Updatexlrator stores its files in a hash of the URL.
> > >=20
> > > The download utility mangles the URL for [+/~], but
> > > the updxlrator only does it for [/]. Thus, download
> > > stores the result as one hash, and updxlrator looks for it
> > > with a different hash. The result is that the file is
> > > re-downloaded every time by both the client, and updxlrator.
> >=20
> > Wouldn't it be a better idea to generally escape/unescape the URLs? There=
 is a
> > perl module that does that:
> >=20
> >    http://search.cpan.org/dist/URI/lib/URI/Escape.pm
> >=20
> > Your changes certainly make sense, but there are more characters that cou=
ld
> > cause the same problem here.
> >=20
> > Let me know if that would make sense, too.
> >=20
> > Best,
> > -Michael
>=20
> I don't know what the impact would be of unescaping more characters. It=20
> might affect negatively
> affect cached downloads - causing them to be redownloaded. So I am=20
> reluctant to do anything
> other than to fix the obvious bug, especially since I'm not at all a=20
> perl programmer.
>=20
> Your portrayal of "my patch fixes some things, but others could cause=20
> the same problem" isn't
> exactly accurate. I'm only fixing the "one module does it one way, but=20
> the other module
> does it another way" problem. In that sense, the two modules are now=20
> identical, and so
> there are no more similar changes that can be made.
>=20
> I'm not sure what "problem" was caused by these characters in the first=20
> place, and why they needed
> to be unescaped. The safest thing is to simply match the download=20
> mangling and leave it at that.
> That's all that I'm comfortable changing - I'm happy if a real=20
> programmer takes over from here and
> looks at the "duplicates" like bug 10344.
>=20
> Updatexlrator is the main tool that keeps us using IPFire, so thanks for=20
> looking at my patches.
> I have one more big one (bug 11558) that I've seriously reworked today=20
> and want to test on my IPFire
> to confirm that it still works as expected.
>=20
> One consideration is that many other people may have made changes to=20
> updxlrator (for adding
> additional caches for example) and since it has been unchanged for so=20
> long they might
> unexpectedly lose those customizations. So, a warning at least is due in=20
> the release notes. It
> might also be good to just hold off on these patches until I get my 4th=20
> one approved. In any case, I hope
> to test it heavily next week, and get it submitted.
> Justin
>=20
>=20
>=20

--===============5456950253166541886==
Content-Type: application/pgp-signature
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="signature.asc"
MIME-Version: 1.0

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUFCQ2dBZEZpRUU1L3JXNWwzR0dl
Mnlwa3R4Z0hudy8yK1FDUWNGQWxwU2VySUFDZ2tRZ0hudy8yK1EKQ1FlN0x3LytNWCtxTHRTQUhi
MHRNOTJWU1hhLzFoMmczWGpsWkpLZGgvTFZOOVNsUUpBc2EydlgvSXNUUnFwMwpvT2ZabVVaVThR
SnRsWGs0QXAzV2FaZGRNbHo2VzllQS9CNU5pTDhENjZyS2JJN3VJOTJxTjJxRkN3eXprdEQ3Ckd3
bDdxendXNUJpREdTN2dpMHJvRTI3aFBMemVJSUsyQU5qSkg2ZFVNbjRYRHVFbUZsNGR1YXZrUnpK
bEdxenEKRFZMZGJmdzBFa0pSV09UcDRDdG1oSVN1NExWZ2NMcnU4b0wwY0xma0xITFNneEw5bWhr
QTkyMnVNWkIzTC8rbQpYSkorY0xxcnhOakplNU5NOGR1OHJhWXErSG5odlh3T0wrd0VleVZPczZk
am8ycjJSc3d0MEwyc2JuU2N2UmdFCnFtR2p6S2lVZ3Fob3cxdkFGUmtiSDhVUktDcmtYRnpBcndh
NjAwTmFITXZ0bjZPZC9ydXU5bFhPbHlnZVVnRVkKTXpiT0NwNUZuVTc4b2p2c1lWSG9NSHpZRnlR
WFBjWVRJbmFCQTR6dzZmOElFQWJqNkRwK0xmbzh5Q3VadUZzeQpORXhWQmFqdWVlS25mVVUzek9n
Q1krMmU5cUNiSGROME5GZEtZSGVWdnp4THkxejlvSmgrb1R2LzRKUHlrcXVxClZuVkFKUUM2elhB
a1o5RkR1RmNuWjNHWlYycnBUcjBFZzJUdFE2RHFJUGJEaUFLZCtXcFp2S3hWNDhTcTFaNVoKWjhV
b012SS9ObGFva1hwVDlQSzI4ZG1PTTM2REJzNExCY3dndFFhZEs5cHpGZ21iaGRQWGpFdWMwTzc1
b1Mrago4bDY3NmZWNll2aG9hblJ5Y2xZR2RNTlhlaFV5UVUxL0o0b0RuVU9Ja3NNTnJ5d0xGYzQ9
Cj05aUhLCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo=

--===============5456950253166541886==--