Re: Various size of (Project) ideas for NetBSD and pkgsrc

[Alistair Crooks <agc%pkgsrc.org@localhost>]

[+Cc: tech-pkg - agc]

Thanks for the list of suggestions - very useful and thought-provoking!

On Sun, Sep 29, 2013 at 10:09:53AM +0900, Ryo ONODERA wrote:
> (2) Create multiple packages from one pkgsrc package directory
> For example, pkgsrc/fonts/harfbuzz has icu option and theoretically
> non-icu part and icu part can be separate package, but splitting
> only icu part from harfbuzz is difficult in configure/build stage.
> In rpm (Red Hat package manager) case, "build once and multiple packages is
> created" is realized with custom do-install target.
> "build once" means reduce of build time.

We discussed this some time ago - this is what OpenBSD used to call
FLAVORS, if I'm not mistaken, and then we (pkgsrc) defined flavors to
mean something else entirely.  Now just because we discussed something
a while ago doesn't mean to say that we can't revisit the discussion,
but I'm not sure what the benefits of the proposed change are.

The way I see it, if I as a normal user wants to build a package, I
know what options I want, and have them set already ahead of time.
Having two separate binary packages with different options on the same
machine is an unusual use case, and not something I'd recommend from
a tearing hair out PoV. And if it's meant for the bulk builders, then
this is usually done on larger machines, where any gain would be minimal.

On the build machines, for building multiple versions of the same
package, typically we'd have to build once with one configuration,
then delete and re-configure with the new configuration, and continue
until binary packages with individual options are built. To avoid
leakage of one option into the next, I don't see there's any other
way (although I might be missing something?) So in the whole scheme
of things, what benefit would we get from this?

Next thing, which is orthogonal, is that the different binary packages
would have to be marked in some way with the options with which they
were built, if we're going to live in a multi-option multiple package
world.  (This world does not scale well, but that, too, is
orthogonal).  So that I can install the harfbuzz+icu package on one
machine, or one LOCALBASE, and the harfbuzz-icu package on another.  I
speak from experience - I used to have a copy of a statically-linked
tcsh which I carried around with me, and one of the admins had a
dynamically linked one; this is before, and the direct reason for
creating, standalone-tcsh. (Actually, size of the package and contents
was the principal way of deciding what was installed, but it was a pain
to have to do that, and it, too, did not scale).

Now I'm probably missing a whole lot of what's intended here, but I
can't see it being a useful addition, or much of a win, for pkgsrc
in general. Can you help me see what's whooshed over my head, please?

> (6) Porting Chromium web browser to NetBSD
> I have not tested build of Chromium (open source edition of Google Chrome),
> and I have a few experience about Google Chrome.
> Chromium may be useful web browser for NetBSD.

Last I heard, Christos had this building - he certainly committed a
number of fixes to src to make this build, but it's such a large thing
that I don't personally have the resources to build it. IIRC, 16 GB RAM
was the killer for me.
 
> (7) Apache OpenOffice for NetBSD
> I have completely no idea about Apache OpenOffice.
> It may be one of the most important application.

Sounds like we're starting to get a number of forks of this, which isn't
surprising. I think most people have migrated to libreoffice, is that a
viable alternative in your view?
 
> (9) Add Microsoft's Hyper-V support to NetBSD
> There is two types of Hyper-V, Windows Server 2012's Hyper-V
> and Windows Server 2012R2's Hyper-V.
> I have heard Windows Server 2012's Hyper-V is supported on
> FreeBSD. But I cannot find the code for it.
> Similar to NetBSD/azure?
> http://wiki.netbsd.org/projects/project/netbsd_on_microsoft_azure/

Yes, this would be neat. :-)
 
> (14) commit mail of www.pkgsrc.org wiki
> I have heard some difficulties, but I do not know it in detail.

If you can find out what this is, I'd be interested (and suspect Amitai
would be, too)
 
> (16) Updating compat_linux
> I cannot run firefox's Linux binary with compat_linux.

Yes, this would be great.
 
> (17) DTrace's syscall provider
> I cannot test riz@'s DTrace syscall provider patch.
> But syscall provider support should be added to NetBSD.

I thought this had been done with the recent changes to *invoke or
similar?
 
> (18) Porting valgrind to NetBSD
> I have heard only old version is available.

I have it building, and put the sources on ftp.netbsd.org. I know it
doesn't work, but that's because I didn't have any time to work on it
any further. Any help would be gratefully received.

        http://ftp.netbsd.org/pub/NetBSD/misc/agc/vg4nbsd-20130226.tar.gz
 
> (22) Creating better conversion tool for CVS to anywhere
> Joerg's src and pkgsrc repositories on github is great, but it seems that
> it has no tags. His tool is not sufficient for moving from CVS
> to somewhere.

See David Holland's recent mail about using mq and mercurial (which isn't
what you're asking, I know)
 
> (23) Lua support for kernel and userland
> Lua is imported to NetBSD base, but nothing uses it.
> And update is not done.
> Lua kernel support should be imported, or remove it from base.

Yes, this seems to be a solution looking for a problem, and we've seen
an instance recently where builtin support for lua was lacking from
pkgsrc. I have a frontend for netpgp for lua (there are ones for python
and perl, too, though), and that doesn't justify lua's existence in
base. cyber had some plans for this at one stage, I don't know how
far he got, though; until then, having lua in 2 different places doesn't
fill me with awe and wonder, but maybe I'm getting old.

Once again, thanks for your suggestions!

Best wishes,
Alistair