Re: ports

[Aleksej Saushev <asau%inbox.ru@localhost>]

Izaac <izaac%setec.org@localhost> writes:

> On Fri, Aug 31, 2012 at 03:30:29PM -0500, Jeremy C. Reed wrote:
>> On Fri, 31 Aug 2012, Izaac wrote:
>> 
>> > All that aside: I'm no apologist for pkgsrc.  I frankly think it's
>> > pretty awful and not a little embarrassing.  But this isn't one of the
>> > things it gets entirely wrong.
>> 
>> I have been studying variety package systems for over a decade on 
>> different systems and consistently keep finding that overall pkgsrc has 
>> been the best for my needs. Can you please share what is awful, 
>> embarrassing, or wrong?  Let's improve it.
>
> "No one pretends that democracy is perfect or all-wise. Indeed, it has
> been said that democracy is the worst form of government except all
> those other forms that have been tried from time to time."
>                                     - Sir Winston Churchill, 1947-11-11
>
> Wise words.  And pkgsrc is very similar to democracy in this case.  Of
> those systems with which I have had experience, it is the most
> versatile, intuitive, and frankly pleasing.
>
> However.
>
> You ask a perfectly valid question, and it deserves a real response.  I
> unfortunately don't have the time right now to perform the appropriate
> analysis.  So here's a few things off the top of my head:
>
> First, let us consider the raw stuff of pkgsrc, i.e. the hierarchy and
> files themselves.  At present, pkgsrc-current consists of 119436 files
> filling 703MiB of disk.  Why so enormous?  Because 84875 of these files
> are one 512-byte block or less in length.
>
> Is CVS to blame?  Partially, sure.  But let's remove it.  The statistics
> are now: 70112 files occupying 447MiB where 36132 are one 512-byte block
> or less.  (But now we can't update.  Not bad for quarterly release,
> except that we release CVS in the tarball anyway.)  This is pretty
> insane, considering that the contents of these files -- sans CVS --
> amount to 159MiB of actual data; a 2.8x inflation.

If your operating system wastes memory, you should blame your operating system,
this is not pkgsrc's competence at all. pkgsrc uses what you have given to it.

If you do care of how much space you waste, then you've got to tune your file 
system.

For instance, consider the smallest practical package.

Makefile size is around 300 octets.
DESCR size is around 200 octets.
distinfo size is around 250 octets.
CVS subdirectory contains three files with sizes around 100, 20, and 30 octets.

Fine, you've got these numbers. Now you can look at newfs(8) and try to
create file system that allocates in smaller blocks than 4K octet ones.

> Second, make(1) is a poor choice for resolving dependencies.

What do you propose instead? Rewriting all 12000+ packages in some
logic or constraint programming language? Going to learn Prolog yourself
and teach everyone else too?

Or do you propose writing LP/CLP engine in something more familiar like Python?

> Third, binary package handling.  Have you ever actually tried something
> like:
>
>    # export PKG_PATH 
> http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/5.1_2012Q2/All/
>    # pkg_add -v calibre
>
> The verbose does absolutely nothing to convey the fact that something is
> being downloaded (presumably in order to read its +FILEs?,) which is why
> the program is just sitting there silently.  And then it love to
> repeatedly advise that:
>
>    pkg_add: Warning: package `thinyoucareabout-3.14.159nb2718' was built for 
> a platform:
>    pkg_add: NetBSD/x86_64 5.1 (pkg) vs. NetBSD/x86_64 5.1.2 (this host)

> (Why, pray tell, don't we have binary packages that are actually built
> for the latest release version of the 5.1 branch, i.e. 5.1.2?  4.0.1 is
> correct.  5.0.2 is correct.  Hell, there's even a 6.0_RC1.  And don't
> get me started on the string inanities of "amd64" and "x86_64".)

http://wiki.netbsd.org/pkgsrc/faq

> (Also, build reproducibility.  There's been some interest in
> reproducible binaries in NetBSD in general.  In pkgsrc, it's
> particularly infuriating to find that the only thing preventing this for
> many packages is BUILD_DATE in +BUILD_INFO.  The ability to retrieve and
> compare +BUILD_INFO and +CONTENTS would be immensely useful to that end.
> Imagine if it could be used to resolve some of the make package
> conflicts as well!)

This is hard. Given that there're more than 12000 packages, it is very very 
hard.

> Fourth, database integrity.  If I had a nickel for every time I've had
> to pkg_admin rebuild / pkg_admin rebuild-tree because something died
> along the way.

If you want to deal with it, then you should start from the question
why not using SQLite for it.


-- 
HE CE3OH...