[LLVMdev] Obsolete PTX is NOT completely removed in 3.2 release

[Brooks Davis]

On Fri, Jan 11, 2013 at 02:47:01PM -0600, Pawel Wodnicki wrote:
> On 1/11/2013 2:40 PM, Brooks Davis wrote:
> > On Fri, Jan 11, 2013 at 09:33:17PM +0100, Benjamin Kramer wrote:
> >> 
> >> On 11.01.2013, at 21:31, Justin Holewinski 
> >> <justin.holewinski at gmail.com> wrote:
> >> 
> >>> On Fri, Jan 11, 2013 at 3:26 PM, Benjamin Kramer 
> >>> <benny.kra at gmail.com> wrote:
> >>> 
> >>> On 11.01.2013, at 07:36, ????????? (Wei-Ren Chen) 
> >>> <chenwj at iis.sinica.edu.tw> wrote:
> >>> 
> >>>> Hi Pawel,
> >>>> 
> >>>> PTX already be replaced with NVPTX. However, PTX subdirectory
> >>>> still sit in lib/Target in 3.2 release. Do you think update
> >>>> the release tarball is a good idea? Also could you remove it
> >>>> from the trunk?
> >>> 
> >>> Please do not, under no circumstances, change the 3.2 release 
> >>> tarballs at this point. They are mirrored around the world now 
> >>> with cryptographic hashes and signatures. Changing them will 
> >>> break things for many people, especially for an extremely
> >>> minor thing like an empty directory.
> >>> 
> >>> I'm not sure if Pawel's tarball change should be reverted now 
> >>> as it already caused uproar, so changing it back might only 
> >>> make matters worse.
> >>> 
> >>> The tarballs were changed?
> >> 
> >> r172208
> > 
> > I finally updated the FreeBSD ports yesterday and today a user 
> > complained about distfile changes.  IMO, this revision should be 
> > reverted or all the other BSDs will have to chase checksums as 
> > well.
> > 
> > If you really want to remove the directory, ship a 3.2.1 tarball 
> > rather than screwing all the downstream consumers who's 
> > infrastructure exists to detect trojan'd tarballs.
> 
> Tarball is signed, it is not trjoan.
> Your infrastructure should be able to deal with it?

The FreeBSD ports collection maintains a set of sha256 hashes for
each distfile.  The system can deal with them changing, but it's an
inconvenience to port maintainers and users.  Even if we did have
infrastructure to verify the signatures we'd still have to check the
contents and would not just trust the signature since there's always a
risk of keys being compromised.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130111/c3ecc424/attachment.sig>