[aur-dev] [PATCH] git-update: Check for missing install and source files

Gordian Edenhofer gordian.edenhofer at gmail.com
Sun May 31 22:00:31 UTC 2015


On Sun, 2015-05-31 at 22:49 +0200, Lukas Fleischer wrote:
> On Sun, 31 May 2015 at 22:09:19, Marcel Korpel wrote:
> > * Daniel Wallace <danielwallace at gtmanfred.com> (Sun, 31 May 2015
> > 14:33:38 -0500):
> > > The names usually end in 'hib' instead of humble bundle, standing 
> > > for
> > > Humble Indie Bundle, but there are several other things out there
> > > that are similar to this.
> > 
> > Ah, now I understand. But those packages contain filenames with 
> > '://'
> > in it, so I think this patch will just let those PKGBUILDs go 
> > through
> > without those files being present, am I right?
> > 
> > Nevertheless, there are other cases I didn't think of, like
> > https://aur.archlinux.org/packages/ttf-ms-win8/ where source files
> > should be provided by the user. Providing zero-length dummy files 
> > looks
> > like a solution, but isn't, as the checksums provided should be 
> > correct
> > against those user-provided files, not the dummy ones.
> > 
> > I can't think of a solution to this at the moment, perhaps someone 
> > else?
> > 
> 
> Why are checksums an issue? You can use the checksum of the correct
> file. It doesn't match the checksum of the dummy file but I don't see
> how that is an issue (it is even good since the user immediately 
> notices
> that something is wrong with the dummy file). Another possibility is 
> to
> tell makepkg to skip the integrity check.
> 
> > And *if* we go for solution 2, it should indeed be well-documented.
> > 
> > Best, Marcel
> > 

I am against dummy files and would even prefer dropping the patch in
favor of a clean processing of files.
Correct me if I am wrong but since the information is extracted from
the .SRCINFO file, the package ttf-m-win8 should work just fine. The
only problem is which files are delivered and which shell be
downloaded. As things stand right now everything with "
://" or "lp:" in its filename is considered an URL and therefore the
present of the file is not checked. This would potentially ignore cases
where those files are omitted though not downloadable. However
considering that this will help the vast majority where this schema
fits, the minority of missing warnings are neglectable.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/aur-dev/attachments/20150601/e84a635b/attachment.asc>


More information about the aur-dev mailing list