public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Jean-Michel Smith <jsmith@kcco.com>
To: Tom Philbrick <tom@wickidpisa.com>, gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] Automatic menus?
Date: Fri, 26 Jul 2002 13:03:27 -0500	[thread overview]
Message-ID: <200207261303.27485.jsmith@kcco.com> (raw)
In-Reply-To: <20020726175337.GA8002@wickidpisa.csh.rit.edu>

On Friday 26 July 2002 12:53 pm, Tom Philbrick wrote:
> On Fri, Jul 26, 2002 at 02:45:05PM +0200, Corvus Corax wrote:
> > Dont want to bother anyone, but the idea of having to rebuild every
> > ebuild existing for menu data seems not very effective.
>
> It would not be very effective, which is why no one, including myself,
> has suggested it. The way this would wor [sic] is, there is a program called
> update-menus that should be called in the ebuild of any program that
> installs a menufile.

It is a tough call where to draw the line of responsiblity.  Do you make 
ebuild maintainers do the work in their ebuild, in which case only those 
whose maintainers have any interest in such a feature will use the feature, 
and the rest will be left out anyway, or do you have an ebuild that maintains 
such files for all the rest of the ebuilds, that a person who is interested 
in the feature can maintain across a bunch of packages (e.g. 
update-menu-configs)?

I think the best solution is one that allows ebuild maintainers to add the 
information for their ebuild if they wish, but also allows other interested 
parties to add information for ebuilds whose maintainers do not have the time 
or interest to maintain that sort of information themselves.

Soemthing like:

#1 an optional ebuild that installs the auto-menu system
#2 an ebuild containing menu information/config info for a plethora of ebuilds 
out there.
#3 a documented means by which individual ebuilds can overlay/override the 
config file in #2 above, or an easy way for ebuild maintainers to submit 
changes/updates to #2 above.

In any event, as long as the feature is optional and not required I have no 
problem with it, though I'm not certain I would use it (I might, though.  I 
was ambivelent with Debian's menu system ... sometimes I liked it, sometimes 
I found it overly convoluted and annoying).

Jean.




  reply	other threads:[~2002-07-29 13:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-24 15:08 [gentoo-dev] Automatic menus? Tom Philbrick
2002-07-24 15:14 ` Jon Nelson
2002-07-24 22:46 ` Peter Ruskin
2002-07-24 23:21   ` Grant Goodyear
2002-07-26 12:45 ` Corvus Corax
2002-07-26 13:19   ` Paul de Vrieze
2002-07-26 17:53   ` Tom Philbrick
2002-07-26 18:03     ` Jean-Michel Smith [this message]
2002-07-29 17:22       ` Tom Philbrick
2002-07-29 10:05 ` Noah Justin Norris
  -- strict thread matches above, loose matches on Subject: below --
2002-07-25  3:11 Thomas Beaudry
2002-07-25 21:15 ` James Gibson
2002-07-25 21:52   ` Jon Nelson
2002-07-26  3:50     ` Felipe Ghellar
2002-07-26  4:47       ` Tom Philbrick
2002-07-26  5:09         ` Felipe Ghellar
2002-07-26  4:23     ` Tom Philbrick
2002-07-26  1:04 Thomas Beaudry
2002-07-26  2:50 ` James Gibson

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=200207261303.27485.jsmith@kcco.com \
    --to=jsmith@kcco.com \
    --cc=gentoo-dev@gentoo.org \
    --cc=tom@wickidpisa.com \
    /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