Hi, From: Alistair Crooks <a...@pkgsrc.org>, 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...@yk.rim.or.jp PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
