Strange contents on some ftp mirrors

[Dominic Fandrey]

On 29/07/2010 01:29, Marcin Wisnicki wrote:
> On Thu, 29 Jul 2010 00:18:01 +0200, Dominic Fandrey wrote:
> 
>> On 28/07/2010 23:24, Andrew W. Nosenko wrote:
>>>
>>> Excuse me?  The ports check downloaded source tarball against SHA
>>> checksum.  Just for nay case like downloading error or malicious
>>> inject.  Did you try to say that binary package have no such safeguard?
>>
>> Exactly. The INDEX does not contain such information. The thing is to do
>> that, the pointyhat INDEX format would have to differ from the ports
>> INDEX format.
>>
> 
> It could be renamed to PKGINDEX.
> 
>> A possiblity of course, but also a source of trouble if the INDEX format
>> of the ports should ever change, something I desire:
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=148783
>>
> 
> It's also missing ranged versions of dependencies like foo>=2.0.
> 
>> Another solution would be to add an empty column that pointyhat can fill
>> in.
> 
> Actually I'd rather have less data in INDEX.
> Some columns have no use in case of packages ({BUILD,FETCH,EXTRACT,PATCH}_DEPENDS).

This INDEX based binary package management hasn't really been done before.
kports can do it, pkg_upgrade does it, and I am told portmaster
now can do it, too.

There's a big wishlist of stuff to go into INDEX. The gist of the whole
thing is, that binary package management ever was an intention, and
all infrastructure in place has not been exposed to practical use
before.

That's why the next version of pkg_upgrade will come with its own INDEX
generator, so people can generate a more useful INDEX for their own package
builds.

> Additional data can be stored in separate files as long as there is some way
> to verify they all belong to same build. It could be some information
> in header (does INDEX support comments?) or some assumption such as that
> modification times may not differ by more than a couple of seconds
> (just touch them all at the end of build).
> 
> I think storing all columns in separate files would be better and allow
> future extensibility.
> For example consider PKGINDEX subdirectory with following files,
> each having one entry per line:
> ...
> I have some awk scripts to produce something like that from INDEX ;)
> 
> General idea is to have sorted files where first column is always a key.
> You can then operate on them using utilities like join(1) and tsort(1).

I think I'll make use of your idea to create separate files and
work with join, provided that the performance suffices. I expect
your way to be faster, when memory is scarce. So especially
useful to update packages on an ALIX or a similarly limited
machine.

I will build my INDEX directly from the present packages, though.
This would be the most reliable way, I assume.

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?