[gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
"Alec Warner" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 21 Sep 2008 18:35:04 -0700: > gentoo-x86 uses bash; the ebuilds, the eclasses, they all rely on it. > I'm pretty sure most package managers rely on bash as well, but I have > not looked at the code outside of portage to verify. > > I really dislike ideas where the compelling argument is 'in the future > we may make a specific decision and that makes that one choice easier.' > If you have a compelling argument for switching the entire tree to POSIX > then give it; however I'm pretty sure it is a difficult argument to make > (Uberlord tried to make it in the past and did not succeed). Otherwise > lets just roll with the bash implementation. ++ This seems to be what it comes down to. Based on past discussion, while individual devs can go POSIX and nobody's going to complain, indeed, they're likely to be respected for taking that position in regard to /their/ /own/ /code/, there's sufficient resistance to making /all/ devs favor POSIX over BASH that it's effectively not even rational to contemplate it at this time, nor is it likely to be for a dev generation or more. Trying to do otherwise is /perceived/ as (note I didn't say it was the /intent/ of, only /perceived/ as) trying to force POSIX down the throat of others, and given the current state requiring bash, turns that respect for devs doing it for their own work on its head -- they're then seen as being an active danger to the ability of devs who don't differentiate between POSIX sh and BASH to continue as devs in good Gentoo standing, with the entirely predictable reaction being to oppose them at nearly any cost. Which pretty much leaves Gentoo depending on BASH now and for the foreseeable future, and there's little point in debating it further or indeed, in "artificially" trying to reduce that dependence, except in one's own work if desired. It's just not worth the fractious debates it causes, particularly when the conclusion is predetermined based on past iterations. We've lost very good developers on this issue in the past. Let's not make it any more, OK? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
Steve Long <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 22 Sep 2008 01:35:57 +0100: >> This is an old rhetorical trick (I don't know its name in English): You >> impute that I claimed things which I never said - of course, then it is >> easy for you to prove that these things are wrong. > What, like saying my point was only about saving two tokens? > >> I _never_ suggested to use code from stone-age for ebuilds > You did as far as I am concerned. Careful please, both of you. This bit looks like it could be headed personal, and I don't believe that's in the interest of anyone. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Making built_with_use die by default with EAPI 2
David Leverton kirjoitti: On Saturday 20 September 2008 18:15:27 Alexis Ballier wrote: I can think of checks like: - foo is a dep/rdep of bar - foo has a "plugin like" architecture - bar will "work" with minimal foo - most people will expect some features in bar that come with foo's plugins - we might want to display warnings for the most useful features - having useflags in bar for each of foo's useflags doesn't seem wise If you mean something like built_with_use cat/foo coolfeature || ewarn "bar will be more useful if you rebuild cat/foo with USE=coolfeature" then you can use has_version 'cat/foo[coolfeature]' || ... instead. What does this report if cat/foo does not have coolfeature use flag in some version? Meaning can this support cases which need --missing true. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: addition of virtual/fonts package
I'm thinking that a virtual/fonts package would be a good addition to the tree. We have hit this issue in Gentoo Prefix where any font package would satisfy a dependency. I also have an open bug where a package depends on corefonts but the reporter has stated that another fonts package will work. Frankly, I would rather *not* depend on the proprietary M$ fonts, myself. So my proposal would be to make every fonts package satisfy some virtual and then other packages can depend on that virtual to satisfy the need for *some* fonts. I just don't have a game plan for the best way to do it. Do you people agree that this could be useful? Does anyone have a suggestion for the best way to get it done? Thanks for reading! -Jeremy
Re: [gentoo-dev] RFC: addition of virtual/fonts package
On Mon, Sep 22, 2008 at 10:03:53PM -0500, Jeremy Olexa wrote: > I'm thinking that a virtual/fonts package would be a good addition to the > tree. We have hit this issue in Gentoo Prefix where any font package would > satisfy a dependency. I also have an open bug where a package depends on > corefonts but the reporter has stated that another fonts package will work. > Frankly, I would rather *not* depend on the proprietary M$ fonts, myself. > So my proposal would be to make every fonts package satisfy some virtual > and then other packages can depend on that virtual to satisfy the need for > *some* fonts. I just don't have a game plan for the best way to do it. Is a single virtual sufficient? Some years ago I pondered having virtuals for some of the combinations of fonts: - format: truetype, T1, pcf, bdf - serif, sans serif - monospace, variable width -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpGAcxMBnJUv.pgp Description: PGP signature
[gentoo-dev] Re: Last rites: x11-terms/root-tail
Jeremy Olexa wrote: # Jeremy Olexa <[EMAIL PROTECTED]> (12 Sep 2008) # Masked for removal in 60 days. dead upstream, missed modular X transition. # See bug #127193 x11-terms/root-tail I have lifted this mask. Multiple users have said that it works and they want it in the tree. I also got it to work with additional research. See the latest comments on bug #127193 if interested.
[gentoo-dev] Last rites: media-sound/slimserver
# Joe Peterson <[EMAIL PROTECTED]> (22 Sep 2008) # Masked for removal in 30 days (see bug #238442) # Replaced by package: media-sound/squeezecenter media-sound/slimserver -Joe
[gentoo-dev] Re: RFC: addition of virtual/fonts package
On Mon, 22 Sep 2008 22:03:53 -0500 Jeremy Olexa <[EMAIL PROTECTED]> wrote: > I'm thinking that a virtual/fonts package would be a good addition to > the tree. We have hit this issue in Gentoo Prefix where any font > package would satisfy a dependency. I also have an open bug where a > package depends on corefonts but the reporter has stated that another > fonts package will work. Frankly, I would rather *not* depend on the > proprietary M$ fonts, myself. So my proposal would be to make every > fonts package satisfy some virtual and then other packages can depend > on that virtual to satisfy the need for *some* fonts. I just don't > have a game plan for the best way to do it. > > Do you people agree that this could be useful? > Does anyone have a suggestion for the best way to get it done? Is it something like currently deps on corefonts but liberation-fonts works? I think there was a bug open somewhere for that at some point. I could see a virtual on a some agreed upon choice of core fonts, but to have every font package in it... There are also lot of packages that depend on ttf-bitstream-vera that might work just as easily with dejavu. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Gentoo Council Reminder for September 25
This is your friendly reminder ! Same bat time (typically the 2nd & 4th Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know! Simply reply to this e-mail for the whole Gentoo dev list to see. Keep in mind that every GLEP *re*submission to the council for review must first be sent to the gentoo-dev mailing list 7 days (minimum) before being submitted as an agenda item which itself occurs 7 days before the meeting. Simply put, the gentoo-dev mailing list must be notified at least 14 days before the meeting itself. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpysTAkIY2zm.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for September 25
On 23:13 Mon 22 Sep , Donnie Berkholz wrote: > If you have something you'd wish for us to chat about, maybe even vote > on, let us know! Simply reply to this e-mail for the whole Gentoo dev > list to see. Here's what I've got so far -- - Approving EAPI=2 - The eapi-2 branch of pms now has a summary of each EAPI's features in an appendix, which was a blocker. - Portage has all of the features implemented as a "2_preX" EAPI (AFAIK), which was another blocker. - PMS as a draft standard. This is the deadline for these 4 requirements: - There needs to be a PMS lead who is a Gentoo dev [calchan]. Both cardoe & antarus volunteered if this was needed. - Document the conflict resolution process that we agreed upon last meeting [calchan]. - Document the patch acceptance process [halcy0n]. - Create a public mailing list so discussions & patches aren't lost on the pms-bugs alias [cardoe]. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpXqvMfWofn5.pgp Description: PGP signature
