Re: [gentoo-dev] Einput eclass
Alright, now it's the latest. Regards, John "Open source, you don't pay back, you pay forward." On 7/24/06, Alex Tarkovsky <[EMAIL PROTECTED]> wrote: On 7/24/06, John Jawed <[EMAIL PROTECTED]> wrote: > Updated version is up at http://jawed.name/dev/gentoo/einput.eclass now. The version you have up there isn't the latest actually, see the attachment in the post you just replied to. :) -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] langs.eclass (deprecating linguas.eclass)
Completly rewritten to be function based and thus more universal: http://gentoo-sunrise.org/svndump/peper/eclass/langs.eclass Also updated firefox patch: http://gentoo-sunrise.org/svndump/peper/mozilla-firefox-2.0_beta1-langs.patch Comments are welcome again :] -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Einput eclass
On 7/24/06, John Jawed <[EMAIL PROTECTED]> wrote: Updated version is up at http://jawed.name/dev/gentoo/einput.eclass now. The version you have up there isn't the latest actually, see the attachment in the post you just replied to. :) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Gentoo Forums - New old project leads
According to the TLP policies, project leads have to be voted upon (or lose the lottery) for each project once a year at least. As a consequence, i've been nice to all the members of the forums project for the last weeks (hey, i even made a trip to the Gentoo UK meeting to bribe Tom and Jonathan with beer). Appearently my plan worked, and i got re-elected - however we decided that instead of project lead and co-leads we're going to have two equal leads - me and Anders (kallamej). This reflects the way we've been working anyway for the last year and is in no way a consequence of an incident involving a ninja, me, a fairy costume and a pony. Tom (tomk) was and will be leader of the technical subproject, which is responsible for risking innocent people's lives and sanity in the dangerous, toxic phpBB mines digging for code. Our (as of this moment) former co lead Ian will also join him in the subproject formally, as he's been doing that stuff anyway more than anything else. So, having said all that formal stuff, i'd also like to thank everyone who helped with the forums project in the last year, be it as a moderator, phpBB hacker, infra monkey, helpful user or someone i just forgot to mention now. I really enjoy Gentoo and especially the forums, so i'm looking forward to the next year. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpu2GGxFFtr8.pgp Description: PGP signature
Re: [gentoo-dev] Einput eclass
Updated version is up at http://jawed.name/dev/gentoo/einput.eclass now. Regards, John "Open source, you don't pay back, you pay forward." On 7/24/06, Alex Tarkovsky <[EMAIL PROTECTED]> wrote: To ensure the global vars play nicely in the Portage environment I've renamed a few, and moved a couple more to functions as locals and literal strings. Also improved on the inline documentation and renamed a couple of functions to something more intuitive. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Einput eclass
To ensure the global vars play nicely in the Portage environment I've renamed a few, and moved a couple more to functions as locals and literal strings. Also improved on the inline documentation and renamed a couple of functions to something more intuitive. einput.eclass Description: Binary data
Re: [gentoo-dev] New category: net-voip
On Mon, 24 Jul 2006 17:50:42 +0200 "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote: | > As I said (and you seemed to have ignored), mandating tree access | > to use the vdb or a standalone binpkg repository == no go. | | I didn't ignore it - I didn't get it when you first said it. What | you're saying (?) is that to install a binpkg (for example), if the | tree is present it would resolve the category that the binpkg was | created under (that is now aliased) to the new category using the | alias data in the tree, and store stuff in the vdb under that new | category, purging out the entry in the vdb from the old category | (hence using tree data in the standalone case). Obviously this is | the correct behaviour when the tree is present. | | I'd suggest that in the absence of a tree, operations would assume no | aliasing (since all aliases at the time the vdb or binpkg were created | would already have been resolved), so the system state is still | consistent with the aliasing in force when the packages were built. Won't work, which is a large part of why this thing isn't as simple as you're assuming. The only way of handling it correctly is to keep track, with *each individual binary / vdb entry*, of all the names that have pointed to it at any given time between when it was created and current... Think through all the cases involving alias changing, removing etc. There're rather a lot of them, and a solution that handles all said cases sanely is unfortunately not going to be anything like straighforward. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Mon, 24 Jul 2006 06:23:59 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: > On Mon, Jul 24, 2006 at 02:47:46PM +0200, Kevin F. Quinn wrote: > > On Sun, 23 Jul 2006 12:19:28 +0100 > > Stuart Herbert <[EMAIL PROTECTED]> wrote: > > > Just adding an alias > > > into a second category makes the tree more of a mess - not less. > > > > The alias, once setup, can be left alone forever. As far as any > > further maintenance is concerned, it requires none. Even if the > > package is moved again, the alias can still point to the second > > location which becomes an alias for the final location. > > That implicitly means that any second level categorizations can never > be removed. By "second level categorizations" do you mean the intermediate alias? The intermediate alias will exist anyway, as an alias in its own right. If any alias is to be removed, then clearly any references to it need to be cleaned up. This is the case whether the alias in question is part of a chain or not. Also this is no worse a situation than current package moves - a fixpackages-style patch-up becomes necessary at that point (more on removal below). Having said all that, I do think the single alias file approach would be better, and it would be simple then to require all aliases to refer directly to the real category. This would indeed require some maintenance, but not exactly back-breaking, just one file for the maintainer of the package that is being moved to check for existing aliases to the previous location. > Like stuart said, makes a bigger mess of the tree. Package moves can > be disruptive enough- trying to shift out a non-real category is > going to be a much larger mess of building that tree and trying to > rewrite atoms as needed. I disagree, it's not a mess. It's better for existing installations as the old CP still works - so to my mind you get the best of both worlds; you can move the package to whatever category the maintainer thinks is the best, without having to hack around all over the place (which currently leaves standalone installations in the dark, btw) to clean up. > > As far as > > users are concerned, assuming aliases are resolved when being > > parsed, they would see: > > > > $ emerge -p net-im/skype > > > > These are the packages that would be merged, in order: > > > > Calculating dependencies... done! > > [ebuild R ] net-voip/skype-1.3.0.30-r1 > > That doesn't strike you as a bit... daft? they asked for net-im, not > net-voip. Yes, under your scheme, they're the same- that still is > far from intuitive. No, it seems simple enough to me. Someone who has previously installed skype from the net-im category, may remember it was in net-im and type the command I illustrated. However the package has moved to net-voip, and emerge has done the right thing - managed the alias and gone to the correct package. If you really wanted to be verbose about it, it could go like: $ emerge -p net-im/skype These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] net-voip/skype-1.3.0.30-r1 [*] [*] package moved to highlight to the user the package has moved. Currently that same user would do: $ emerge -p net-im/skype These are the packages that would be merged, in order: Calculating dependencies emerge: there are no ebuilds to satisfy "net-im/skype". [bum - where has Skype gone? hmm; perhaps it's somewhere else] $ $ emerge -p net-voip/skype ... Note that since alias names would be ignored if the category is not specified, 'emerge -p skype' would just work in the way it does now. Note also that if a new package is added with the same name, and that package goes in what was once an alias location, the package manager requires you to specify which one you want. > > The only "mess" is that we end up with the alias data in the tree > > and that gradually accumulates. > > Err... cruft accumulating in the tree is a no go. What, like eclasses and ChangeLogs? It's history, rather than cruft. It has meaning to existing installations, as does legacy code in eclasses. I illustrated elsewhere that it could easily be implemented by a simple text file, nothing more intrusive than package.mask et. al. > > However it won't change once it's first > > setup so won't incur any significant synchronisation overhead > > (beyond the overhead for the actual move as done currently). > > A) potential of circular aliasing (fun fun) Circular aliasing is obviously broken and should not be committed. Any such occurrences should be fixed promptly, and the committer slapped. It's also easy to detect. However it's a good reason to require all aliases to be direct (i.e. no aliases of aliases). > B) potential of aliasing multiple pkgs to the same cat (fun fun) Ditto :) > C) pkgs that grow capabilities after a certain version, thus they now > belong in a new category. Now we require full atoms for aliasing > (which means lo
[gentoo-dev] seamonkey -> nss vs nspr
Hi folks, while emerging seamonkey I've seen something strange on nspr and nss: these packages are both imported by seamonkey, but it seems that nss contains nspr. Do we have some duplicates here ? cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] mozilla{-bin}/gecko-sdk masking
* Ned Ludd <[EMAIL PROTECTED]> schrieb: Hi, > Lack of time is fully understandable. It's a big package and takes a > long time to compile and debug. Yeah, IMHO the whole mozilla stuff has been grown too big. nspr already should be fall apart into several packages, the XUL core another one, each XUL toolkit for each own, etc, etc. This would make developing much, much easier and most of the patches don't have to be ported across several branches (ie. moz vs. ff), since these branched package would be quite small, but sitting on top of several libs. But this of course is an upstream issue ... cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Mon, Jul 24, 2006 at 02:47:46PM +0200, Kevin F. Quinn wrote:
> On Sun, 23 Jul 2006 12:19:28 +0100
> Stuart Herbert <[EMAIL PROTECTED]> wrote:
> > Just adding an alias
> > into a second category makes the tree more of a mess - not less.
>
> The alias, once setup, can be left alone forever. As far as any
> further maintenance is concerned, it requires none. Even if the
> package is moved again, the alias can still point to the second
> location which becomes an alias for the final location.
That implicitly means that any second level categorizations can never
be removed.
Like stuart said, makes a bigger mess of the tree. Package moves can
be disruptive enough- trying to shift out a non-real category is going
to be a much larger mess of building that tree and trying to rewrite
atoms as needed.
> As far as
> users are concerned, assuming aliases are resolved when being parsed,
> they would see:
>
> $ emerge -p net-im/skype
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild R ] net-voip/skype-1.3.0.30-r1
That doesn't strike you as a bit... daft? they asked for net-im, not
net-voip. Yes, under your scheme, they're the same- that still is far
from intuitive.
> The only "mess" is that we end up with the alias data in the tree
> and that gradually accumulates.
Err... cruft accumulating in the tree is a no go.
> However it won't change once it's first
> setup so won't incur any significant synchronisation overhead (beyond
> the overhead for the actual move as done currently).
A) potential of circular aliasing (fun fun)
B) potential of aliasing multiple pkgs to the same cat (fun fun)
C) pkgs that grow capabilities after a certain version, thus they now
belong in a new category. Now we require full atoms for aliasing
(which means lookup gets more complicated now, and slower)
D) all tree access now must pass through aliasing. Additionally, now
all equality tests must now rely on aliasing to determine if two
pkgs from seperate categories are actually the same pkg (slower, and
far more complicated)
Fair amount of thorny issues introduced there, for (imo) no real gain.
> I've mentioned the
> /alias idea elsewhere, however that's not the only way to do it -
> one simple method could be to have a simple text file (e.g.
> ${PORTDIR}/profiles/alias) listing all the aliases. That's no mess at
> all:
>
> example alias file contents
> # Alias category/package Resident category
> net-im/skype net-voip
>
As I said (and you seemed to have ignored), mandating tree access to
use the vdb or a standalone binpkg repository == no go.
~harring
pgpIr8sQDiWLN.pgp
Description: PGP signature
Re: [gentoo-dev] New category: net-voip
Stuart Herbert wrote: > Kevin F. Quinn wrote: >> An advantage to this approach is that package moves just become aliases >> - existing stuff doesn't break yet you get the new categorisation as >> well. > > That's actually a disadvantage. The whole point of moving a package is > to take it *out* of its existing category. Just adding an alias into a > second category makes the tree more of a mess - not less. +1 I really dislike this idea of aliasing ebuild categories, yuck... Way better to fix what needs to be fixed to make package moves as smooth and seamless as possible. -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New category: net-voip
On Sun, 23 Jul 2006 12:19:28 +0100
Stuart Herbert <[EMAIL PROTECTED]> wrote:
> Kevin F. Quinn wrote:
> > An advantage to this approach is that package moves just become
> > aliases
> > - existing stuff doesn't break yet you get the new categorisation as
> > well.
>
> That's actually a disadvantage. The whole point of moving a package
> is to take it *out* of its existing category.
No, the point is to take it from a category where it's membership is
not so strong, to one where it is stronger. For exmaple, it's not that
net-im is the wrong place for skype, it's just that net-voip is in some
ways better. Where categorisation is clearly very wrong then it should
be moved as soon as possible (for example if skype had initially been
placed in www-apps) but that's an initial commit problem rather than
maintenance going forward.
> Just adding an alias
> into a second category makes the tree more of a mess - not less.
The alias, once setup, can be left alone forever. As far as any
further maintenance is concerned, it requires none. Even if the
package is moved again, the alias can still point to the second
location which becomes an alias for the final location. As far as
users are concerned, assuming aliases are resolved when being parsed,
they would see:
$ emerge -p net-im/skype
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] net-voip/skype-1.3.0.30-r1
(where net-voip/skype is copied from net-im/skype, then net-im/skpe is
rewritten as an alias), which is clear and simple (it's hardly more
than what emerge does if you only give it the package name). Aliases
can be ignored when the category is not specified (unless we permit
aliasing with different package names, which I suggest we do not).
Similarly with 'emerge -s' - it would return the canonical CP.
The only "mess" is that we end up with the alias data in the tree
and that gradually accumulates. However it won't change once it's first
setup so won't incur any significant synchronisation overhead (beyond
the overhead for the actual move as done currently). I've mentioned the
/alias idea elsewhere, however that's not the only way to do it -
one simple method could be to have a simple text file (e.g.
${PORTDIR}/profiles/alias) listing all the aliases. That's no mess at
all:
example alias file contents
# Alias category/package Resident category
net-im/skype net-voip
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Sat, 22 Jul 2006 13:35:08 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: > On Sat, Jul 22, 2006 at 06:04:10PM +0200, Kevin F. Quinn wrote: > > On Fri, 21 Jul 2006 01:05:20 -0700 > > Brian Harring <[EMAIL PROTECTED]> wrote: > > > > > > >Unfortunately the category system is deeply embedded in portage > > > > >and the tree, so changing that system is simply not going to > > > > >happen, which is why I've stopped whinging about the semantic > > > > >inadequacy of the system. > > > > > > > > Instead of whinging about why the existing categories are bad, > > > > why not instead put forward an alternative (preferably with > > > > code, but a clear and consistently argued position would be a > > > > start) for something better? Otherwise, you *are* going to be > > > > ignored ... and with good reason. > > > > > > Just so we're clear, I probably will wedgie anyone who suggests > > > trying to extend the existing tree format with N categories per > > > pkg- sounds nice on paper, but it makes lookup a serious pita- > > > sys-apps/portage, we'll pretend it's actually located in sys-apps, > > > and it's also in category 'pkg-managers'. An atom states > > > 'pkg-managers/portage'; how does a pkg manager do a lookup for it? > > > > Since the names would be aliased, either reference would be fine > > i.e. a dep on pkg-managers/portage would be equivalent to > > sys-apps/portage. > > > > If it were to be implemented with symlinks (implying one entry is > > "real" and the others are aliases) the package manager just needs to > > canonicalise any symlinked CPs it comes across. > > > > Since we can't have symlinks in CVS, there are other ways it can be > > done; first thing that pops into my head is an "alias" package > > entry in the tree, where instead of ebuilds & files/ etc it would > > just contain a file "alias" with the category (and perhaps package > > name) of the aliased package. > > > > I would expect it to be non-trivial to implement in portage, since > > portage code has evolved for so long assuming that a package is in > > one category - I'm not saying portage code is bad, I'm just saying > > that much of it may have been implemented under that assumption and > > breaking it means testing lots of stuff. > > > > > Has to walk the entire tree... so if N category per pkg is going > > > to be proposed, need to preserve the fast lookup that's there now. > > > > I don't think the above ideas cause any substantial change to the > > amount of processing required. > > > > An advantage to this approach is that package moves just become > > aliases > > - existing stuff doesn't break yet you get the new categorisation as > > well. > > A disadvantage being that without a tree, your graph is broken > (aliases live in the tree); this includes using strictly a bintree > (remote or otherwise). I don't get what you're talking about here; perhaps I'm missing something. I don't see why the deps can't be managed by canonicalising every reference as they are parsed. As you build the graph, the aliases disappear as they are canonicalised before they reach the graph. That way the only place aliases exist is in the portage tree itself - the package manager can forget about them once it has parsed the deps. Certainly trying to build the dependency tree without canonicalising aliases would be a mess; anyone trying to do it like that is asking for trouble. You want unique names for everything for which you're building the dependency tree. > Big disadvantage, hence why that approach was ignored last time it > was brought up. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Sat, 22 Jul 2006 21:42:07 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Sat, 22 Jul 2006 18:04:10 +0200 "Kevin F. Quinn" > <[EMAIL PROTECTED]> wrote: > | If it were to be implemented with symlinks (implying one entry is > | "real" and the others are aliases) the package manager just needs to > | canonicalise any symlinked CPs it comes across. > > Not that simple. Think about installed packages, overlays and changing > aliases. The package manager would need to keep track of what aliases > were at any given time. Not if the aliases are resolved to the canonical CP when they are parsed. At any point in time, the dep resolver would be working with canonical CPs as they exist at that point, not what they were when the package was installed or the binpackage was built. > Then there're symlinks to outside the tree and Maybe I've misunderstood you here, but surely aliasing from inside the tree to outside it (e.g. to an overlay package not present in the primary tree) would not be sensible. > circular symlinks... There's a lot more too it than is initially > obvious. My understanding is that circular dependencies are not supported; the situation would be no different with aliasing, pretty much by definition if nothing else - all aliases should ultimately resolve to a real package, which they can't do if you allow circular aliases. > | Since we can't have symlinks in CVS, there are other ways it can be > | done; first thing that pops into my head is an "alias" package entry > | in the tree, where instead of ebuilds & files/ etc it would just > | contain a file "alias" with the category (and perhaps package name) > | of the aliased package. > > Files are cleaner than symlinks for other reasons too. Also allows the > opportunity of making 'deprecated' aliases that issue QA warnings. > > | > Has to walk the entire tree... so if N category per pkg is going > to | > be proposed, need to preserve the fast lookup that's there now. > | > | I don't think the above ideas cause any substantial change to the > | amount of processing required. > > Perhaps you should think. It's nowhere near as straight forward as you > claim. Which is not to say it's not doable, just that it's not doable > cheaply... I still don't see how, if aliases are canonicalised when they are parsed, the issue becomes more complex. Internally the package manager would always think in terms of the canonical CP, at which point it's not doing anything that it isn't already. -- Kevin F. Quinn signature.asc Description: PGP signature
[gentoo-dev] What is a devrel bug?
Unfortunately, the audience for this note most likely comprises people
who will not see it, but perhaps it will be useful anyway. However,
it's been a while since I've sent a long, rambling note, so here we
go
Once or twice a week, devrel ((Gentoo) Developer Relations) is assigned
a new bug of the form "I updated sci-calculators/units and it now claims
that 1 light year = 4 mm." While this would be a bug, it is not one
devrel can do anything about: As the name suggests, devrel is concerned
with people, not with packages, and devrel does not address problems
like a misbehaving "units" package. When we get such a report, we have
to notice we have an inappropriate bug, then reassign it. This serves
only to annoy us and to delay a resolution for the reporter. Please do
not assign software bugs to devrel.
That said, now that I have your attention, I'll continue a bit with some
suggestions describing what a good devrel bug might be. Devrel bugs are
concerned generally with recruiting developers, retiring developers, and
conflicts between developers. I am focusing on the last of these.
A few months ago I floated an RFC (attached, and at
http://dev.gentoo.org/~fmccor/devrel/DevrelBug.rfc.txt ) outlining some
thoughts on what information is useful for helping devrel sort out a bug
in which one developer is complaining about some other developer's
behavior and is requesting some sort of devrel intervention. The RFC
was not met with hostility, so I am sending it on to this mailing list
for feedback and suggestions.
Please note that the RFC refers to devrel policy, and that the policy is
undergoing revision. However, this does not affect the RFC; it affects
only what the RFC is referring to.
Although it is not emphasised in the RFC, I should add that when you
have such a complaint, it really helps everybody (including you) if you
try to resolve it by other means before filing a bug. In case you do
not remember, we have an ombudsman group ([EMAIL PROTECTED]) within
devrel whose charter is just that: help to mediate a solution before
escalating the problem to a level where you probably don't want it. I
note in passing that actually most devrel members will help resolve such
problems if you ask them (in case you have a favorite devrel member
whose style you are comfortable with), but if you do that, be prepared
for a referral to the ombudsman or working with that particular devrel
member's own eccentricities (e.g., if you ask me, be prepared for very
long ("may I have 5 minutes please?") discussions on IRC; others prefer
to work with email, etc.).
If you are still with me, thanks for your attention.
Regards,
Ferris
--
Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]>
Developer, Gentoo Linux (Devrel, Sparc)
THOUGHTS ON EFFECTIVE DEVREL PERSONNEL BUGS
== = == =
I. BACKGROUND
A bug reporting some developer's inappropriate behavior is similar to a
bug reporting some package's inappropriate behavior. And for devrel to
process such a personnel bug effectively and correctly, we need as much
context information as posible, just as the package maintainer needs as much
information as possible to process a failure report.
("fmccor is a disrespectful and incompetent developer" is as hard to do much
with as is "gcc is broken because it won't compile any of my programs".)
However, now that I have had time to gain some experience reviewing
devrel personnel bugs, I can say that this background information is sometimes
missing. Because of this, we (devrel) can miss the point of the report,
misclassify it, underreact (leading to "devrel never does anything"), or
overreact (leading to "devrel is just looking for reasons to hammer me").
This is frustrating, it slows the process, and it works to no one's benefit.
Consequently, here are some thoughts about information to include in a
bug reporting a misbehaving developer.
II. CONTENT
Generally, conform to the analogy to a product bug, or consider the form
of a legal brief for that matter. In some rational order (not fixed, but
perhaps depending on the bug), some or all of the following information can be
useful.
A. Brief (one or two sentence) summary of what the bug is about. If
possible, use the Bugzilla Summary field for this.
B. "Jurisdiction" --- why this is something for devrel to consider (policy
violation or whatever). This is a categorization of the report, not an
argument why it is valid. (This could be handled by a predefined set of
reasons by an existing Bugzilla field similar to "Component," but currently
it is not.)
C. What happened --- what specifically you are reporting. This is a
recounting of the incident(s) triggering the report. It should include
context and background information, as explicit as possible description of the
problem, and generally what you believe to be relevant. If you are re
Re: [gentoo-dev] linguas.eclass
Complete rewrite is comming so wait with comments plz. -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Einput eclass
Updated version. I had forgotten to remove the case-insensitive stuff from einput_list(). Input is now case-sensitive, as ebuild devs may want, for example, "r" and "R" to represent two different (but related) choices. Also did a little tidying. einput.eclass Description: Binary data
Re: [gentoo-dev] Einput eclass
On 7/23/06, John Jawed <[EMAIL PROTECTED]> wrote: Nice work on this, it's looking good now. Is there a reason the leading asterisk was dropped? Having it there might be good for readability as well as keeping in line with the "look here" (einfo, eerror, ewarn, etc) motif in portage. I was indeed attempting to keep with the established look and feel of Portage tools here, and in this case the appearance of the "emerge -a" prompt seemed a more appropriate model than the appearance of the non-interactive einfo(), ewarn(), and eerror() messages. The reason the latter are prefixed with colored asterisks is because they're non-interactive and need some way to catch the user's eye amidst other messages flying by in the terminal. In contrast, an interactive prompt such as "emerge -a" doesn't really need to stand out in the same way because it's going to sit there in the user's face until it receives input. I did make the prompt text bold to be consistent with the look of "emerge -a", and this consistency is what we should go for IMO because the only time users are likely to run into einput.eclass's prompts is when it's being called from an ebuild running in an "emerge" session. I feel it's quite arguable which style looks better (bolded or asterisked), and if it's decided to go with fuchsia asterisks for einput's prompts after all, emerge's prompts should also be changed to maintain consistency. -- gentoo-dev@gentoo.org mailing list
