Prev: LICENSE questions
Next: deskutils/alexandria: maintainer timeout more than 1 month
From: Marcin Wisnicki on 28 Jul 2010 19:40
On Thu, 29 Jul 2010 00:23:58 +0200, Dominic Fandrey wrote:

> On 28/07/2010 23:36, Marcin Wisnicki wrote:
>>
>> What do you mean by master ? If you think about ftp-master then it's
>> password protected. AFAIK there is no publicly available ftp site that
>> is an authoritative source, ftp.freebsd.org is synced just like any
>> other mirror.
>> You can see in my initial post that it was even less up-to-date than
>> ftp.fr.freebsd.org.
>
> Well, I never had a download of an INDEXED package fail from one of the
> unnumbered servers, so there ought to be something different, because
> the remaining mirrors normally only are able to provide ~20% of them.
>

Well, ftp.fr.freebsd is not numbered and it just failed.
In the past I had problems with ftp.freebsd.org.
In fact there may be even problems with ftp-master. Not so long ago
uploaded package of openjdk6 was truncated on every mirror.
Though it's something that you really can't defend against :(

> Any way, in pkg_upgrade terms master is whichever server is chosen to
> provide the index. Everything else downloaded will be checked to be
> consistent with that one.
>
> It's not about getting the latest packages, but about getting a
> consistent set.

Indeed, that's why you can't trust mirrors.
And since there is no other source to trust you must do as much sanity
checking as possible.

_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Dominic Fandrey on 29 Jul 2010 02:31
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?
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

First  |  Prev  | 
Pages: 1 2 3 4
Prev: LICENSE questions
Next: deskutils/alexandria: maintainer timeout more than 1 month