Re: Strange contents on some ftp mirrors
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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Strange contents on some ftp mirrors
On Tue, 27 Jul 2010 21:03:21 -0700, perryh wrote: Marcin Wisnicki mwisnicki+free...@gmail.com wrote: At this very moment, french package mirror has INDEX newer than in other mirrors: ... yet it does not have those packages. How could something like this happen ? By being examined while a resync was in process: evidently the new INDEX file had been transferred but that package file (and likely others) were still in transit or perhaps not even started yet. Mirroring is not an instantaneous process. Yeah that was it, but it is really, really bad. Mirroring must be atomic (mirror to temporary directory then rename). Otherwise there is a large window of time every couple of days when upgrading packages will at best fail or leave you with broken system. I did binary upgrade with pkg_upgrade yesterday and half of my system was linked against wrong libintl version :( In fact atomic mirroring will not fix it completely, you must keep older versions of packages for at least a few hours after mirroring so anyone that started before mirroring was commited will have a chance to finish. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Strange contents on some ftp mirrors
On Wed, 28 Jul 2010 13:15:42 +, Marcin Wisnicki wrote: Yeah that was it, but it is really, really bad. Mirroring must be atomic (mirror to temporary directory then rename). Otherwise there is a large window of time every couple of days when upgrading packages will at best fail or leave you with broken system. I did binary upgrade with pkg_upgrade yesterday and half of my system was linked against wrong libintl version :( In fact atomic mirroring will not fix it completely, you must keep older versions of packages for at least a few hours after mirroring so anyone that started before mirroring was commited will have a chance to finish. Thinking a bit more, even *that* won't save you from broken system at the end of upgrade as it happened to me yesterday since packages keep their versions when rebuilt with different incompatible dependencies. Awww crap, whole package thing on FreeBSD is broken by design :( I guess the only possible fix for upgrades in the middle of mirroring would be to have completely immutable repositories with timestamp in their name and then some file that points to latest complete repository. Older repositories could be deleted after some time. Actually there are even programs based on rsync (liek rsnapshot) that do something similar. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Strange contents on some ftp mirrors
Mirroring must be atomic (mirror to temporary directory then rename). That could double disc requirement, reduce mirror sites willing to provide space ? Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text. Not HTML, Not quoted-printable, Not Base64. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Strange contents on some ftp mirrors
On Wed, 28 Jul 2010 15:43:43 +0200, Julian H. Stacey wrote: Mirroring must be atomic (mirror to temporary directory then rename). That could double disc requirement, reduce mirror sites willing to provide space ? Indeed it would. But there is no other way to solve it. Alternatively it could be prevented with no disk cost by putting MIRROR-IN-PROGRESS file and making all package utilities check for its existence and fail with explanation to try again later. Cheers, Julian ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Strange contents on some ftp mirrors
Marcin Wisnicki wrote: On Wed, 28 Jul 2010 15:43:43 +0200, Julian H. Stacey wrote: Mirroring must be atomic (mirror to temporary directory then rename). That could double disc requirement, reduce mirror sites willing to provide space ? Indeed it would. But there is no other way to solve it. Alternatively it could be prevented with no disk cost by putting MIRROR-IN-PROGRESS file and making all package utilities check for its existence and fail with explanation to try again later. Perhaps a less visible /or top listing semaphore of ./.MIRROR-IN-PROGRESS ? Content could be empty, or mirror master could generate into it, eg: Version:Number of format of .MIRROR-IN-PROGRESS\n Master-URL: Of master\n Protocol: Of mirror\n Date: (GMT) start of mirror\n Contact:If mirror fails\n Text: Any other text.\n EOR:End of record\n Various FreeBSD etc stuff gets mirrored as nested directories, so one might want to to be able to check up to N steps up the parent tree structure for lock(s). One might also want an optional force- fetch- regardless flag. Awkward conditions to allow for: What if mirror is not mirroring when you start your fetch, but is when you finish ? What if mirror is not mirroring when you start your fetch, then mirror starts finishes a mirror before you finish your fetch ? One might want to generalise a mechanism that could be added to multiple tools, eg ports/net/ mirror/ rdist6/ rsync/ ?... http://wiki.freebsd.org/FreeBSDMirrors by EdwinGroothuis (edwin@) mentions orphan/ stale mirrors. Perhaps some are even cascaded mirrors ? I don't see anything in: http://www.freebsd.org/projects/ideas/ideas.html The FreeBSD list of projects and ideas for volunteers Maybe someone might add something ? See also: mirror-ad...@freebsd.org http://wiki.freebsd.org/IvanVoras/pkg_patchhttp://wiki.freebsd.org/IvanVoras/pkg_patch Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text. Not HTML, Not quoted-printable, Not Base64. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Strange contents on some ftp mirrors
On 28/07/2010 15:15, Marcin Wisnicki wrote: On Tue, 27 Jul 2010 21:03:21 -0700, perryh wrote: Marcin Wisnicki mwisnicki+free...@gmail.com wrote: At this very moment, french package mirror has INDEX newer than in other mirrors: ... yet it does not have those packages. How could something like this happen ? By being examined while a resync was in process: evidently the new INDEX file had been transferred but that package file (and likely others) were still in transit or perhaps not even started yet. Mirroring is not an instantaneous process. Yeah that was it, but it is really, really bad. Mirroring must be atomic (mirror to temporary directory then rename). Otherwise there is a large window of time every couple of days when upgrading packages will at best fail or leave you with broken system. I did binary upgrade with pkg_upgrade yesterday and half of my system was linked against wrong libintl version :( The next version of pkg_upgrade will check every downloaded package against the master server after completing the download. I expect to release it at the end of September. Regards -- 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Strange contents on some ftp mirrors
On Wed, 28 Jul 2010 17:39:17 +0200, Dominic Fandrey wrote: On 28/07/2010 15:15, Marcin Wisnicki wrote: On Tue, 27 Jul 2010 21:03:21 -0700, perryh wrote: Marcin Wisnicki mwisnicki+free...@gmail.com wrote: At this very moment, french package mirror has INDEX newer than in other mirrors: ... yet it does not have those packages. How could something like this happen ? By being examined while a resync was in process: evidently the new INDEX file had been transferred but that package file (and likely others) were still in transit or perhaps not even started yet. Mirroring is not an instantaneous process. Yeah that was it, but it is really, really bad. Mirroring must be atomic (mirror to temporary directory then rename). Otherwise there is a large window of time every couple of days when upgrading packages will at best fail or leave you with broken system. I did binary upgrade with pkg_upgrade yesterday and half of my system was linked against wrong libintl version :( The next version of pkg_upgrade will check every downloaded package against the master server after completing the download. Great, I need this so much. Currently to really upgrade packages I must do something like: rm -rf /usr/ports/packages pkg_upgrade -af to make sure rebuilt packages are refetched. But it's obviously suboptimal. I think you could also detect inconsistent mirror by comparing modification time of package against mtime of INDEX. If pkg is newer than INDEX then it's a sign of incomplete sync. I expect to release it at the end of September. Regards ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Strange contents on some ftp mirrors
On Wed, 28 Jul 2010 17:11:25 +0200, Julian H. Stacey wrote: Marcin Wisnicki wrote: Alternatively it could be prevented with no disk cost by putting MIRROR-IN-PROGRESS file and making all package utilities check for its existence and fail with explanation to try again later. Perhaps a less visible /or top listing semaphore of ./.MIRROR-IN-PROGRESS ? Content could be empty, or mirror master could generate into it, eg: Version:Number of format of .MIRROR-IN-PROGRESS\n Master-URL: Of master\n Protocol: Of mirror\n Date: (GMT) start of mirror\n Contact:If mirror fails\n Text: Any other text.\n EOR:End of record\n Various FreeBSD etc stuff gets mirrored as nested directories, so one might want to to be able to check up to N steps up the parent tree structure for lock(s). Unfortunately no scheme involving global lock files will really work. I've read http://wiki.freebsd.org/FreeBSDMirrors that you linked and it mentions TIMESTAMP files that it uses to monitor mirrors quality. You just need to visit $random[1] freebsd mirror and look at that file then check packages directory. You will find that it can have latest timestamp yet many months old files. In other words, mirrors cannot be trusted. For now however I've found and suggested in sibling post a workaround that should mostly work assuming INDEX file gets mirrored before packages (and it looks like it is). [1] random = ftp.pl.freebsd.org, but it's not the only one One might also want an optional force- fetch- regardless flag. Awkward conditions to allow for: What if mirror is not mirroring when you start your fetch, but is when you finish ? What if mirror is not mirroring when you start your fetch, then mirror starts finishes a mirror before you finish your fetch ? Solving any of this, in a way that does not require intervention of user if it happens, requires that file content at given url is immutable (or doesn't exist). There is simply no other 100% reliable way. You can however do some sanity checks and fail early if failing is acceptable. Some ideas: 1. if (mtime(pkg) mtime(INDEX)) fail(Mirror sync in progress); 2. Fetch timestamps of all requested packages in one go before fetching contents; do it again and compare to be sure nothing changed; fetch actual packages and fail if mtime/size does not match. 3. Do 1 or 2 but fetch timestamps from well known source or multiple sources. You may also find most up-to-date mirror this way. One might want to generalise a mechanism that could be added to multiple tools, eg ports/net/ mirror/ rdist6/ rsync/ ?... ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Strange contents on some ftp mirrors
On 28/07/2010 17:58, Marcin Wisnicki wrote: On Wed, 28 Jul 2010 17:39:17 +0200, Dominic Fandrey wrote: On 28/07/2010 15:15, Marcin Wisnicki wrote: On Tue, 27 Jul 2010 21:03:21 -0700, perryh wrote: Marcin Wisnicki mwisnicki+free...@gmail.com wrote: At this very moment, french package mirror has INDEX newer than in other mirrors: ... yet it does not have those packages. How could something like this happen ? By being examined while a resync was in process: evidently the new INDEX file had been transferred but that package file (and likely others) were still in transit or perhaps not even started yet. Mirroring is not an instantaneous process. Yeah that was it, but it is really, really bad. Mirroring must be atomic (mirror to temporary directory then rename). Otherwise there is a large window of time every couple of days when upgrading packages will at best fail or leave you with broken system. I did binary upgrade with pkg_upgrade yesterday and half of my system was linked against wrong libintl version :( The next version of pkg_upgrade will check every downloaded package against the master server after completing the download. Great, I need this so much. Currently to really upgrade packages I must do something like: rm -rf /usr/ports/packages pkg_upgrade -af to make sure rebuilt packages are refetched. But it's obviously suboptimal. I think you could also detect inconsistent mirror by comparing modification time of package against mtime of INDEX. If pkg is newer than INDEX then it's a sign of incomplete sync. True, but if the check does not fail it still doesn't mean that the package is valid. Checking against the master (it will check size and time) is the safest method, I think -- 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Strange contents on some ftp mirrors
On Wed, 28 Jul 2010 20:02:40 +0200, Dominic Fandrey wrote: On 28/07/2010 17:58, Marcin Wisnicki wrote: I think you could also detect inconsistent mirror by comparing modification time of package against mtime of INDEX. If pkg is newer than INDEX then it's a sign of incomplete sync. True, but if the check does not fail it still doesn't mean that the package is valid. Checking against the master (it will check size and time) is the safest method, I think 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. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Strange contents on some ftp mirrors
On Wed, Jul 28, 2010 at 18:39, Dominic Fandrey kamik...@bsdforen.de wrote: On 28/07/2010 15:15, Marcin Wisnicki wrote: On Tue, 27 Jul 2010 21:03:21 -0700, perryh wrote: Marcin Wisnicki mwisnicki+free...@gmail.com wrote: At this very moment, french package mirror has INDEX newer than in other mirrors: ... yet it does not have those packages. How could something like this happen ? By being examined while a resync was in process: evidently the new INDEX file had been transferred but that package file (and likely others) were still in transit or perhaps not even started yet. Mirroring is not an instantaneous process. Yeah that was it, but it is really, really bad. Mirroring must be atomic (mirror to temporary directory then rename). Otherwise there is a large window of time every couple of days when upgrading packages will at best fail or leave you with broken system. I did binary upgrade with pkg_upgrade yesterday and half of my system was linked against wrong libintl version :( The next version of pkg_upgrade will check every downloaded package against the master server after completing the download. 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? I expect to release it at the end of September. -- Andrew W. Nosenko andrew.w.nose...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Strange contents on some ftp mirrors
On 28/07/2010 23:24, Andrew W. Nosenko wrote: On Wed, Jul 28, 2010 at 18:39, Dominic Fandrey kamik...@bsdforen.de wrote: On 28/07/2010 15:15, Marcin Wisnicki wrote: On Tue, 27 Jul 2010 21:03:21 -0700, perryh wrote: Marcin Wisnicki mwisnicki+free...@gmail.com wrote: At this very moment, french package mirror has INDEX newer than in other mirrors: ... yet it does not have those packages. How could something like this happen ? By being examined while a resync was in process: evidently the new INDEX file had been transferred but that package file (and likely others) were still in transit or perhaps not even started yet. Mirroring is not an instantaneous process. Yeah that was it, but it is really, really bad. Mirroring must be atomic (mirror to temporary directory then rename). Otherwise there is a large window of time every couple of days when upgrading packages will at best fail or leave you with broken system. I did binary upgrade with pkg_upgrade yesterday and half of my system was linked against wrong libintl version :( The next version of pkg_upgrade will check every downloaded package against the master server after completing the download. 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. 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 Another solution would be to add an empty column that pointyhat can fill in. -- 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Strange contents on some ftp mirrors
On 28/07/2010 23:36, Marcin Wisnicki wrote: On Wed, 28 Jul 2010 20:02:40 +0200, Dominic Fandrey wrote: On 28/07/2010 17:58, Marcin Wisnicki wrote: I think you could also detect inconsistent mirror by comparing modification time of package against mtime of INDEX. If pkg is newer than INDEX then it's a sign of incomplete sync. True, but if the check does not fail it still doesn't mean that the package is valid. Checking against the master (it will check size and time) is the safest method, I think 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. 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. -- 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Strange contents on some ftp mirrors
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).
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:
# PKGINDEX/format:
MANDATORY org.freebsd.PKGINDEX 1
OPTIONAL com.mycomany.PKGINDEX 1
# this one actually has custom format
# list base format and extensions
# mandatory must be supported by client, optional can be ignored
# i'm probably overengineering here a little ;)
# PKGINDEX/packages.list:
bar-2.0
baz-3.2
foo-1.0
# *.list files are just lists (ordered alphabetically)
# PKGINDEX/run-depends.map:
foo-1.0 bar-2.0
foo-1.0 baz=3.1
# *.map files have key value+ pairs (ordered alphabetically)
# in this case foo needs bar baz
# in future it could support boolean operators
# e.g.:
# foo-1.0 (bar-2.0 || bar-alternate=2.0)
# foo-1.0 (baz=3.1 baz4.0)
# where '-' is soft requirement like currently implemented in pkg_add
# new operators would be strictly enforced
# PKGINDEX/category.map:
foo-1.0 sysutils databases devel
# sysutils is primary category of foo-1.0
# additional categories follow in alphabetic order
# PKGINDEX/origin.map:
foo-1.0 sysutils/foo
# PKGINDEX/description.map:
bar-3.2 Bar is better than foo
foo-1.0 Foo is great
etc...
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).
Having potentially large but rarely used attributes like description
in separate files greatly reduces amount of text needed to be loaded and
parsed by utilities in common operations.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Strange contents on some ftp mirrors
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Strange contents on some ftp mirrors
Marcin Wisnicki mwisnicki+free...@gmail.com wrote: At this very moment, french package mirror has INDEX newer than in other mirrors: ... yet it does not have those packages. How could something like this happen ? By being examined while a resync was in process: evidently the new INDEX file had been transferred but that package file (and likely others) were still in transit or perhaps not even started yet. Mirroring is not an instantaneous process. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
