From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Date: Sun, 16 May 2010 15:44:24 -0600 From: EBo To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: References: <6aaf2d79af665bf1905db13e44e194e5@quanstro.net> <3c68655ad1dadf393d44b4a945abbd7a@swcp.com> <26f3b3b7fc6f7e8e8d90094305925bdd@kw.quanstro.net> <05efeb46a13b81ef20914458e84cdd9f@swcp.com> Message-ID: <932700d9bb1c81831186e7aeb809fd9f@swcp.com> User-Agent: RoundCube Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] nupas update Topicbox-Message-UUID: 253adcf8-ead6-11e9-9d60-3106f5b1d025 > i've tried to make this point several times before. > i think it is an error to envision what somebody > might want. build want you want. respond to > complaints. do not build stuff speculatively. Thank you for your clarity. I was hoping to open a discussion and get some feedback so when I do my thing it would likely be more useful. When starting new projects I typically start with a basic idea, then take it to what I call its illogical extreme, and then whittle it back down to the initial project. It is part of how I get a handle on what the scope of work looks like. I guess that approach is in error for 9fans, but it works quite well for me personally. >> Another potential use flag or architecture keyword covers if the package >> can be built, or should build, using 64 bit mode. > > there is no 64 bit kernel. Will there ever be? Or is that even an appropriate question? > please, no use flags. we can't test what we've got. use > flags make the problem go factorial. (gentoo for example > doesn't work if you set the profile use flag.) Now we are getting to the heart of a very important matter. I agree that use flags causes the dependency graph to go factorial -- but pruned to the number of use flags implemented in each ebuild (so it is not factorial to the number of accepted use flags). The situation I am dealing with regards to TinyCoreLinux is that they require that the documentation and source be broken out into separate packages. So, I have currently implemented this as separate portage ebuilds for convenience. But to make this work generally, and for long term maintainability, I have to either implement them as 3*packages or implement this as a "doc source" use flags and possibly an independent ROOT. The advantage of use flags here is that the source and documentation build is kept together. The disadvantage is that building in use flags increases the complexity somewhat, but is it more than what is saved by including them? I do not know. If I do implement use flags I only see the need for maybe 3 or 4, at least for my uses. I've been bitten in the past by separating parts of a logical package at the package level, but seperate source/docs are required, and I see how this will make things easier when I have time to play with embedded systems again. But this discussion demonstrates my point exactly. If I had not opened the discussion we would not have had the above exchange. I would have simply implemented something with use flags and then when you objected later and I would unlikely be willing to rip it out without really good cause or motivation. Best regards, EBo --