9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: EBo <ebo@sandien.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] nupas update
Date: Sun, 16 May 2010 15:44:24 -0600	[thread overview]
Message-ID: <932700d9bb1c81831186e7aeb809fd9f@swcp.com> (raw)
In-Reply-To: <ce0e4d5dc958e76b666c33c8c52f2f3d@kw.quanstro.net>


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



  reply	other threads:[~2010-05-16 21:44 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-03  2:16 erik quanstrom
2009-09-03  2:29 ` David Leimbach
2009-09-03  2:37   ` erik quanstrom
2010-05-15 23:17 ` Akshat Kumar
2010-05-15 23:45   ` erik quanstrom
2010-05-16  2:36     ` ron minnich
2010-05-16  4:15       ` erik quanstrom
2010-05-16  4:28       ` Akshat Kumar
2010-05-16  4:35         ` ron minnich
2010-05-16  4:39           ` erik quanstrom
2010-05-16  4:51             ` ron minnich
2010-05-16  4:57           ` Akshat Kumar
2010-05-16  5:44             ` ron minnich
2010-05-16 13:42               ` EBo
2010-05-16 14:03                 ` erik quanstrom
2010-05-16 14:51                   ` Ethan Grammatikidis
2010-05-16 15:37                     ` EBo
2010-05-16 15:53                       ` Ethan Grammatikidis
2010-05-16 16:02                         ` ron minnich
2010-05-16 17:10                           ` Ethan Grammatikidis
2010-05-16 17:19                           ` EBo
2010-05-16 15:21                   ` EBo
2010-05-16 15:42                     ` Ethan Grammatikidis
2010-05-16 17:34                       ` EBo
2010-05-16 17:47                         ` hiro
2010-05-16 18:58                         ` Corey
2010-05-16 19:29                           ` EBo
2010-05-18 21:35                           ` Georg Lehner
2010-05-18 22:07                             ` ron minnich
2010-05-16 15:46                     ` Jorden M
2010-05-16 15:59                       ` Ethan Grammatikidis
2010-05-16 15:42                   ` Jorden M
2010-05-16 18:24                     ` erik quanstrom
2010-05-16 18:49                       ` EBo
2010-05-16 20:44                         ` erik quanstrom
2010-05-16 21:44                           ` EBo [this message]
2010-05-17  1:17                             ` erik quanstrom
2010-05-17  1:52                               ` EBo
2010-05-17  1:58                                 ` erik quanstrom
2010-05-17  1:35               ` Akshat Kumar
2010-05-17  4:09                 ` ron minnich
2010-05-17  4:19                   ` erik quanstrom
2010-05-17  4:56                     ` ron minnich
2010-05-18 23:50                   ` Federico G. Benavento
2010-05-18 23:59                     ` ron minnich
2010-05-19  0:40                       ` Jorden M
2010-05-19  1:40                         ` Robert Ransom
  -- strict thread matches above, loose matches on Subject: below --
2009-08-06 15:23 erik quanstrom
2008-10-23  0:08 erik quanstrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=932700d9bb1c81831186e7aeb809fd9f@swcp.com \
    --to=ebo@sandien.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).