Package download statistics
dragonflybsd at marino.st
Sun Jun 2 07:41:37 PDT 2013
On 6/2/2013 16:24, Andrey N. Oktyabrski wrote:
> On 02.06.2013 16:32, John Marino wrote:
> I think it will be too much revolutions. Drop i386, drop pkgsrc
Nobody said anything about dropping pkgsrc. ftigeot noted that less
that 1% of binary downloads are pkgsrc, which is an incredible number
considering pkgsrc has been in place for 7 years and was overwhelmingly
displaced by an *experimental* system in a single month. He suggested
that it was not worth our effort to provide pre-built binaries when 99%
of downloads are not for pkgsrc.
> what next? Drop dfly and use freebsd? Please do not make hasty decisions :-)
A bit snarky, don't you think?
>> The bigger question, of course, is *why* pkgsrc users are likely to
>> build from source? Could it be that they had lots of issues with that
>> in the past? Who wouldn't want something fast and quick if it were
>> trustworthy? The "indication" alone is telling.
> Why you see that package download statistics (IMHO):
> 1. All users want to try dports - even if they use pkgsrc.
Except you can't mix these systems. That would explain dports numbers
(presumably on throw-away VMs) but not dismal pkgsrc numbers. Those
should have remained normal if they are indeed being used.
> 2. Many people are afraid of this message:
> pkg_add: Warning: package `ipcalc-0.41nb1' was built for a platform:
> pkg_add: DragonFly/x86_64 3.3 (pkg) vs. DragonFly/x86_64 3.4 (this host)
yes, this is incredibly annoying.
> 3. Many users compile their packages with options. Some packages require
> accepting license. For example:
> $ grep '^PKG_OPTIONS' /usr/pkg/etc/mk.conf | wc -l
> $ grep '^ACCEPTABLE_LICENSES' /usr/pkg/etc/mk.conf | wc -l
Theoretically only the custom-option packages need rebuilding --
building all from source is a waste.
> 4. You do not do regular bulk builds. So if I want recent package, I
> must refresh pkgsrc tree from anoncvs.netbsd.org and build it from sources.
pkgsrc branches should be regularly rebuilt, however we are not talking
about many packages that get pulled up after branching though. If you
are talking about "refreshing pkgsrc tree" then that implies building
from master branch which is NOT the recommended approach.
I think this criticism *is* valid as previously pkgsrc builds were not
updated frequently, but it shouldn't cause everyone to build from source.
Any way you slice it, the ratio between pkgsrc and dports is astounding.
I certainly wasn't expecting these numbers.
More information about the Users