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

[Ryo ONODERA <ryo_on%yk.rim.or.jp@localhost>]

Hi,

From: Alistair Crooks <agc%pkgsrc.org@localhost>, Date: Mon, 30 Sep 2013 
04:26:07 +0200

> [+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?

I belive that multiple packages from one package directory is useful.


>> (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.

Hmm...
According to LinuxBuildInstructionsPrerequisites document at project's site,
8 GB RAM is lower limit.
http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites

I have no 4 GB over RAM machine...

>> (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?

I am working on LibreOffice 4.1.1.2 now. See pkgsrc-wip/libreoffice4.

A administrator of famous anonymous ftp site in Japan says
Apache OpenOffice is downloaded more than several times LibreOffice.
I have heard LibreOffice is more easy to build than Apache OpenOffice,
and I have started to package LibreOffice.
But name of OpenOffice is more famous than LibreOffice at least in
Japan.
So some people will want to use it.

>> (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)

I do not know in detail.
I will post e-mail to netbsd-docs@ mailing list later.

>> (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?

It seems http://www.tastylime.net/netbsd/systrace.diff is not applied to
NetBSD current.

I want to use DtraceToolkit.
http://www.brendangregg.com/dtrace.html#DTraceToolkit
It requires syscall provider.

>> (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

Interesting!
Please complete porting!

>> (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)

I will read http://wiki.netbsd.org/users/dholland/mercurial/ later.

>> (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.

I had requested update of Lua, and I had gotten "it will be updated recently"
reply. But nothing is done. I feel it is abandoned.

By the way, Justin Cormack's LuaJIT work is good news for me.

Thank you.

--
Ryo ONODERA // ryo_on%yk.rim.or.jp@localhost
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3