public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Tom Philbrick <tom@wickidpisa.com>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] Automatic menus?
Date: Mon, 29 Jul 2002 13:22:26 -0400	[thread overview]
Message-ID: <20020729172226.GA14414@wickidpisa.csh.rit.edu> (raw)
In-Reply-To: <200207261303.27485.jsmith@kcco.com>

On Fri, Jul 26, 2002 at 01:03:27PM -0500, Jean-Michel Smith wrote:
> 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.

I believe that Mandrake uses the #2 method, but I can not say that I
really like it. My main problem with it is that whoever is in charge of
that one giant package of menufiles is responsible for understanding
every single package in the portage system. If you know what is in a
package then writing a menufile would only take 30 seconds or so, but it
is not so easy when you have to find out what is in a package and what
it does before you can write it.
Keeping the menufiles with the packages they belong to is the more
appropriate thing to do in my oppinion, and we shouldn't let lazy
maintainers change that. If a maintainer does not add a menufile for
their package, then you should submit a bug about it. That way the menu
entry at least gets looked at by the maintainer, in case they disagree
with part of it, or so they kow about it in case they want to chage
something about it in the future.
If after a while we see that it really isn't working out, then we can
always do a big menufile package at that time.


  reply	other threads:[~2002-07-29 17:22 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
2002-07-29 17:22       ` Tom Philbrick [this message]
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=20020729172226.GA14414@wickidpisa.csh.rit.edu \
    --to=tom@wickidpisa.com \
    --cc=gentoo-dev@gentoo.org \
    /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