[pacman-dev] [PATCH] dload: don't download sig if package is found in cache

Dave Reisner d at falconindy.com
Mon Feb 18 15:40:26 EST 2013


On Feb 17, 2013 11:12 PM, "Allan McRae" <allan at archlinux.org> wrote:
>
> On 18/02/13 12:55, Dave Reisner wrote:
> > Avoids the segfault seen in FS#33911.
> >
> > Signed-off-by: Dave Reisner <dreisner at archlinux.org>
> > ---
> > This is sort of an easy cop-out, but also perhaps the right thing to
do? If we
> > blindly append .sig to the URL we have then we're just going to end up
back at
> > the problem which commit 27067b137286a4 attempted to solve, but without
the aid
> > of being able to know what the followed URL is (since we didn't download
> > anything).
>
> So...  if you have "RemoteFileSigLevel = Required" and only have the
> package and not the signature in the cache, this will not download the
> signature and give a corrupt package warning.
>
> Is that situation fine to "ignore"?  Or should we test both the file and
> the signature are present before skipping the step?   I almost think it
> would make sense to always download the file when using a URL with
> "pacman -U".
>
> Allan

I explicitly fixed the scenario where we look in the file cache for the
package, but we can't always know beforehand because of redirects and usage
of a temp filename.

That said, we can probably make this logic smarter than it currently is.

>
>
> >  lib/libalpm/dload.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c
> > index 280eaaf..7513822 100644
> > --- a/lib/libalpm/dload.c
> > +++ b/lib/libalpm/dload.c
> > @@ -688,7 +688,7 @@ char SYMEXPORT *alpm_fetch_pkgurl(alpm_handle_t
*handle, const char *url)
> >       }
> >
> >       /* attempt to download the signature */
> > -     if(ret == 0 && (handle->siglevel & ALPM_SIG_PACKAGE)) {
> > +     if(ret == 0 && final_pkg_url && (handle->siglevel &
ALPM_SIG_PACKAGE)) {
> >               char *sig_filepath, *sig_final_file = NULL;
> >               size_t len;
> >
> >
>
>


More information about the pacman-dev mailing list