Drake Wyrm wrote:
Jakub Moc <[EMAIL PROTECTED]> wrote:
Well, I don't think so... If I want to enable a feature for one
specific ebuild and a USE flag in /etc/portage/package.use pulls in a
dep, that in turn enables that use flag globally, it's obviously not
what I intended and forces me to add
Jason Stubbs wrote:
Repositories will be user-labelled. However, all that readers need be
concerned with is how to extract the repository name from the news.unread
file and how to then resolve that to a directory name, regardless of how
repositories are implemented.
Expanding on this a litt
Ciaran McCreesh wrote:
On Tue, 13 Dec 2005 11:39:14 +0900 Jason Stubbs <[EMAIL PROTECTED]>
wrote:
| And how can that be adapted to work with overlays, completely
| ignoring the possibility of distinct repositories. Overlays is
| something that exists already and news support for them is a request
For reference, I'm quoting this snippet from earlier in the thread:
Jason Stubbs wrote:
On Sunday 11 December 2005 10:35, Ciaran McCreesh wrote:
.. Note:: Future changes to Portage involving support for multiple
repositories may require one news list per repository. Assuming
repositories have s
Ciaran McCreesh wrote:
| soon. The solution to that seems simple to me. Rather than have
| 'package manager' do anything, just have it provide hooks that will
| allow you to do your thing at the times you want.
Exactly what I am doing. Hence why I'm not making Portage know any more
than it reall
Ciaran McCreesh wrote:
| Local news delivery *should* still be using the user label. Unique
| repo internal labels don't matter to glep42, since the label that
| news delivery _should_ use is what the user's configuration has named
| it.
|
| Just stating it, since tagging a unique id into the
Ciaran McCreesh wrote:
| Brian agreed with you that the extended dep syntax will be necessary
| at some point in the future. I also agree. So, knowing that glep 42
| doesn't require extended depset syntax, can we stop playing this game
| and just settle on something like newsdir="$(portageq new
Ciaran McCreesh wrote:
On Fri, 16 Dec 2005 14:17:13 -0800 Zac Medico <[EMAIL PROTECTED]> wrote:
| > What the heck is this 'gentoo' thing, and how does it help? Shoving
| > newsdir into portageq doesn't help *at all* with multiple repository
| > support.
|
| L
Dan Meltzer wrote:
Like I said in a previous email, 'gentoo' corresponds to 'magic-chicken' in
your news-magic-chicken.unread files. The news reader app gets the repo
identifier from the news-*.unread files and plugs that into portageq to get the
directory where the corresponding new items c
Zac Medico wrote:
Ciaran McCreesh wrote:
except that it moves it deeper down into the "how
do I determine whether this news item is relevant?" area. And the only
way to get around that would be to move even more code into Portage
than you're already proposing.
Are the curr
Ciaran McCreesh wrote:
Well, that depends... If you have sys-apps/foo installed from the
gentoo-x86 repository, and the breakmygentoo repository issues a news
item about sys-apps/foo, should it be displayed?
Well, probably not. Off hand, perhaps portageq could provide a query that
returns som
Harald van Dijk wrote:
Don't know if it's been reported as a portage bug, but this would show
it:
KEYWORDS="~x86"
src_install() {
dodir /test
dosym /usr/bin /test
}
When unmerging, portage won't remove /test/bin because its target still exists.
That is fixed in portage-2.0.53
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
> On Fri, 19 May 2006 15:13:48 +0200
> Stefan Schweizer <[EMAIL PROTECTED]> wrote:
>
>> Marc Hildebrand wrote:
>>> Otoh LC_ALL=C could help if you intend to use a .utf-8 locale as
>>> root, though. So if it does help solving bugs a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
> On Wednesday 07 June 2006 11:13, Brian Harring wrote:
>> 1) requires modifying the tree, and introduction of eclass for it.
>
> this is a *huge* con ... developers are lazy, *i'm* lazy ... i certainly do
> not want to go thr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Grant Goodyear wrote:
> Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT]
>> Mike Frysinger wrote:
>>> this is a *huge* con ... developers are lazy, *i'm* lazy ... i
>>> certainly do not want to go through every singl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner wrote:
> debug-build can always be expanded to turn on generic debugging
> for other build systems and languages.
Really? Perhaps you can explain the implementation details a little
more, because it's not obvious to me. From my perspecti
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
> On Wednesday 07 June 2006 16:10, Zac Medico wrote:
>> Grant Goodyear wrote:
>>> Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT]
>>>> Mike Frysinger wrote:
>>>>> this is a *huge*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Harring wrote:
> Well, all that's required is modification to rsync gen script;
I'll do it, assuming that a location has been agreed upon.
$PORTDIR/metadata/herds.xml is the place?
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner wrote:
> Interested in
> figuring out what use flags were turned off? Check out
> /usr/portage/profiles/base/use.defaults and other use.defaults files
> that correspond to your profile.
It's probably easier to let portage do the work and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marijn Schouten (hkBst) wrote:
> Hi list,
>
> files installed by portage to ${ROOT} do not have the same time stamps
> as the same files
> in ${D}.
Any timestamp difference here is not due to portage itself (since
portage-2.1.3). The timestamp change
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Long wrote:
> Zac Medico wrote:
>> It's currently possible for ebuilds to call the insopts, diropts,
>> exeopts, and libopts functions to modify these variables. If they
>> add the -p option, then timestamps will
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Łukasz Damentko wrote:
> Zac Medico zmedico
Thank you for the nomination. However, I will decline because there
other things that I would prefer to focus on.
Zac
-BEGIN PGP SIGNATURE-
Version: Gn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alin Năstac wrote:
> Portage no longer install ._cfg_* files for the CONFIG_PROTECTed
> files touched by the user. Even if I remove the package and reinstall it
> again, the protected file will remain like it is.
>
> Can someone enlighten me?
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
It might good to add support for a new RESTRICT=live value in
ebuilds. By specifying this value, an ebuild would be able to
indicate that it uses src_unpack() to download sources from some
type of live repository such as cvs, darcs, git,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arfrever Frehtes Taifersar Arahesis wrote:
> 2008-08-02 04:02:48 Zac Medico napisał(a):
> The names of other RESTRICT values are related to features which are
> restricted. The new proposed value is intended for live ebuilds so its
> na
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Auty wrote:
> It seems,
> Slightly like an abuse of the RESTRICT variable. I had thought that
> RESTRICT was generally for when a normal ebuild needed a feature turning
> off (such as mirroring, strict checking and hopefully one day ccache).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Santiago M. Mola wrote:
> On Sat, Aug 2, 2008 at 12:26 PM, Zac Medico <[EMAIL PROTECTED]> wrote:
>> Mike Auty wrote:
>>
>>> If there's need for a new class of ebuild information (such as a new
>>> way
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Auty wrote:
> Zac Medico wrote:
> | Honestly I don't care what the existing scheme is.
>
> Fair enough, I don't maintain the code or have to deal with the
> complaints. It seems a waste to abandon an existing scheme
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arfrever Frehtes Taifersar Arahesis wrote:
> 2008-08-02 04:02:48 Zac Medico napisał(a):
> The names of other RESTRICT values are related to features which are
> restricted. The new proposed value is intended for live ebuilds so its
> na
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
René 'Necoro' Neumann wrote:
> Zac Medico schrieb:
>> I chose "live" because I think it's easy for people to associate it
>> with "live ebuilds", which I believe is a common term used to refer
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas de Grenier de Latour wrote:
> On 2008/08/01, Zac Medico <[EMAIL PROTECTED]> wrote:
>
>> It might good to add support for a new RESTRICT=live value in
>> ebuilds.
>
> Since some people have a problem with t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Avuton Olrich wrote:
> On Fri, Aug 1, 2008 at 7:02 PM, Zac Medico <[EMAIL PROTECTED]> wrote:
> For some of us in the peanut gallery it'd also be nice to document the
> pitfalls of grepping inherited to determine if it's a l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas de Grenier de Latour wrote:
> On 2008/08/02, Zac Medico <[EMAIL PROTECTED]> wrote:
>
>> USE flags are something that can be enable or disabled
>
> Here, what the flag would enable/disable is belonging of live package
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan wrote:
> "Nirbheek Chauhan" <[EMAIL PROTECTED]> posted
> [EMAIL PROTECTED], excerpted
> below, on Sun, 03 Aug 2008 05:37:10 +0530:
>
>> How about we just skip the reversed-boolean-usage/it's-a-long-name
>> confusion/argument and just call it R
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vaeth wrote:
> Sorry that this is slightly OT, but maybe one should think
> about this point in this discussion:
>
>> It seems like USE would be an unconventional location to store that
>> information and I'm not sure that it really belongs in the ebu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joe Peterson wrote:
> However, I do see the point about the RESTRICT variable. Throwing
> random flags into it does not seem ideal, and I think convenience should
> take a back seat to correctness when designing, e.g., ebuild
> syntax/rules. But why
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zac Medico wrote:
> Joe Peterson wrote:
>> However, I do see the point about the RESTRICT variable. Throwing
>> random flags into it does not seem ideal, and I think convenience should
>> take a back seat to correctness when de
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joe Peterson wrote:
> Yes, that's sort of what I am thinking. Migrate options that really do
> not belong in RESTRICT to another variable (and keep them in RESTRICT,
> of course, for backward compat for now). Then introduce new ones into
> whichever
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joe Peterson wrote:
> I'm not sure the "EBUILD_" in "EBUILD_FLAGS" would be necessary
> (redundant?). Maybe even "OPTIONS" or "PROPERTIES" makes more sense.
> In fact, "FLAGS" might be a little too generic, even? Worth a short
> discussion.
One pote
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joe Peterson wrote:
> I'm not sure the "EBUILD_" in "EBUILD_FLAGS" would be necessary
> (redundant?). Maybe even "OPTIONS" or "PROPERTIES" makes more sense.
> In fact, "FLAGS" might be a little too generic, even? Worth a short
> discussion.
I think
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
As a substitute for the previously discussed RESTRICT=live value[1],
I'd now like you to consider an equivalent PROPERTIES=live-sources
setting. By specifying PROPERTIES=live-sources, an ebuild will be
able to indicate that it uses src_un
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I'd like you all to consider a PROPERTIES=virtual setting that
allows an ebuild to indicate that it installs no files and serves
only as a layer of dependency indirection. This will be another use
for the new PROPERTIES metadata variable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Sun, 03 Aug 2008 18:52:43 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>> As a substitute for the previously discussed RESTRICT=live value[1],
>> I'd now like you to consider an equiv
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Tue, 05 Aug 2008 22:15:11 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>> Does this seem like a desirable way to represent the "virtual"
>> attribute? Any suggestions?
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Tue, 05 Aug 2008 22:55:06 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>> Would having the ebuild perform locking be unportable or introduce
>> any undesirable complexity? Does it really need
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello again,
Please consider a new PROPERTIES=interactive setting that allows an
ebuild to indicate that it uses stdin and stdout for user
interaction sometime during the pkg_setup and/or src_unpack phases
(similar to GLEP 52 [1]). This will be anothe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner wrote:
>> Just to be clear; PROPERTIES is a space separated list of items correct?
I was thinking that it might support the same syntax as RESTRICT,
which includes support for USE conditionals.
Zac
-BEGIN PGP SIGNATURE-
Version: G
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello everyone,
Given the vast number of possible choices to consider when defining
new PROPERTIES values [1], perhaps we should create a ballot and
hold a vote on definitions that people have submitted. I suppose
that voters would be able to vote yes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> What's wrong with just discussing it until we agree? Why do you think a
> compromise is necessary?
I think voting might be an interesting approach. We'll see if anyone
else is interested. I don't know yet. :)
Zac
-BEGIN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
> Getting the bot out there
> -
> If you would like to have the new bot in your #gentoo-* channel, would
> each channel founder/leader please respond to this thread, stating the
> channel name, and that t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeremy Olexa wrote:
>> Please consider a new PROPERTIES=interactive setting that allows an
>> ebuild to indicate that it uses stdin and stdout for user
>
> I don't think anyone will disagree with this one. The one problem that I
> see is that if the e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
Please consider the introduction of a new "PROPERTIES" variable to
the ebuild metadata cache that's distributed via the rsync mirrors
and resides locally in the ${PORTDIR}/metadata/cache/ directory.
This variable is intended to have ident
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello again,
I'd like to get some feedback about what people would like to have
in the final EAPI 2. In planning for this EAPI bump, we should
strike a balance somewhere in between everything that we'd like to
have and whatever we can implement in a s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Wed, 13 Aug 2008 01:18:33 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>> * The old src_compile phase function is split into separate
>>src_configure and src_compile fuctions.
>
&
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Petteri Räty wrote:
> Zac Medico kirjoitti:
>>
>> * Default phase function implementations for older EAPIs are
>>accessible via functions having names that start with 'eapi',
>>followed by the EAPI valu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alin Năstac wrote:
> Every once in a while, I get bitten by the $Id keyword replacement done
> on patches in $FILESDIR.
>
> Can we do something to fix this annoyance? If repoman cannot add -kb for
> *.patch and *.diff files, at least it should verify
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
William Hubbs wrote:
>> As of Portage 2.2 the world set does not include the system
>> set any more. If you want emerge --update --deep @world to
>> update the system set too, you need to add @system to the new
>> world_sets file in /var/lib/portage/.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
At least a few people have expressed a desire to have support for a
package.keywords file in the profiles [1] as a means to add or
subtract any number values to or from the KEYWORDS that apply to a
given ebuild. This would allow a specifi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
Please consider a PROPERTIES=live value that, when set in an ebuild,
will serve to indicate that the ebuild will use some form of "live"
source code that may vary each time that the package is installed.
The intention is for PROPERTIES=li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
Since there were some questions about ambiguity in the meaning of
the proposed PROPERTIES=virtual [1] value, we need to clarify it.
Just as the "live" property [2] is intended to have a pure and
simple meaning, so is the "virtual" propert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
It seems that it will be beneficial to narrow the definition of the
proposed PROPERTIES=interactive [1] value, so the definition is more
pure and simple like ones recently suggested for "live" [2] and
"virtual" [3] properties. Therefore,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donnie Berkholz wrote:
> On 13:39 Sat 23 Aug , Zac Medico wrote:
>> Please consider a PROPERTIES=live value that, when set in an ebuild,
>> will serve to indicate that the ebuild will use some form of "live"
>> sour
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michal Kurgan wrote:
> On Sun, 24 Aug 2008 14:01:48 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hi everyone,
>>
>> Since there were some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Volkov wrote:
> В Вск, 17/08/2008 в 17:24 -0700, Zac Medico пишет:
>> At least a few people have expressed a desire to have support for a
>> package.keywords file in the profiles [1] as a means to add or
>> subtract any num
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> So are all zero-install-cost metapackages virtuals now? What about, for
> instance, kde-base/kde?
Looking at the dependencies of kde-base/kde, it seems like it would
be eligible to exhibit the "virtual" property. Perhaps it wo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Mon, 25 Aug 2008 12:06:35 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>> Ciaran McCreesh wrote:
>>> So are all zero-install-cost metapackages virtuals now? What about,
>>> for insta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan wrote:
> I therefore believe I like just moving them all to a *virtual*/ category
> better, thus obviating the need for that particular property in the first
> place.
This has been suggested elsewhere in the thread [1] but I think the
the PRO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan wrote:
> Zac Medico <[EMAIL PROTECTED]> posted [EMAIL PROTECTED],
> excerpted below, on Tue, 26 Aug 2008 10:44:22 -0700:
>
>> Duncan wrote:
>>> I therefore believe I like just moving them all to a *virtu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michal Kurgan wrote:
> On Tue, 26 Aug 2008 18:49:12 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>
>> The PROPERTIES approach still seems a lot simpler and practical to
>> me. It seems to me that the approach invo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zac Medico wrote:
> Michal Kurgan wrote:
>> On Tue, 26 Aug 2008 18:49:12 -0700
>> Zac Medico <[EMAIL PROTECTED]> wrote:
>
>>> The PROPERTIES approach still seems a lot simpler and practical to
>>> me.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
Please consider a blocker syntax extension, for inclusion in EAPI 2,
which will serve to indicate that conflicting packages may be
temporarily installed simultaneously when upgrading or installing a
series of packages. When temporary sim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Volkov wrote:
> В Сбт, 23/08/2008 в 13:39 -0700, Zac Medico пишет:
>> Please consider a PROPERTIES=live value that, when set in an ebuild,
>> will serve to indicate that the ebuild will use some form of "live"
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
Please review and discuss the following features which are proposed
for inclusion EAPI 2. As mentioned in my previous email [1], in
planning for this EAPI bump, we should strike a balance somewhere
in-between everything that we'd like to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Leverton wrote:
> 2008/9/4 Zac Medico <[EMAIL PROTECTED]>:
>> * The 'unpack' helper function recognizes ;sf=tbz2 and ;sf=tgz
>> extensions, for interoperability with gitweb.
>>
>> * SRC_U
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Leverton wrote:
> 2008/9/5 Zac Medico <[EMAIL PROTECTED]>:
>> Both approaches are essentially equivalent but it's a little simpler
>> for ebuild writer if they don't have to customize the output file name.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> a) PROPERTIES can't be used to implement any mandatory feature
This is true in the absence of an EAPI bump. However, for
completeness, I'd like to mention that it is possible to specify
that a given PROPERTIES value have manda
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Petteri Räty wrote:
> Ciaran McCreesh kirjoitti:
>> On Tue, 09 Sep 2008 16:31:08 +0300
>> Petteri Räty <[EMAIL PROTECTED]> wrote:
>>> Jorge Manuel B. S. Vicetto kirjoitti:
and cardoe's earlier request to the council ml, can the council
member
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Petteri Räty wrote:
> Zac Medico kirjoitti:
>> Petteri Räty wrote:
>>
>> Are you saying that the docs in my dev space don't count?
>>
>> http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donnie Berkholz wrote:
> Here's the agenda. I'm eagerly awaiting submission of EAPI 2, whenever
> folks are ready.
I've updated the EAPI 2 draft to remove the eapi* functions and the
gitweb unpack extension as mentioned earlier in Jorge's email [1].
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Wed, 10 Sep 2008 23:43:54 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>> [2] http://dev.gentoo.org/~zmedico/portage/eapi/eapi-2-draft.html
>
> By table 6.11, are you implying that you consider th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Mon, 08 Sep 2008 23:34:28 +
> "Jorge Manuel B. S. Vicetto" <[EMAIL PROTECTED]> wrote:
>> So we're talking about adding the following to EAPI-2:
>
> Are we treating PROPERTIES as purely optional and having no defined
> v
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bo Ørsted Andresen wrote:
> On Thursday 11 September 2008 17:42:25 Zac Medico wrote:
>> Ebuilds that used this approach were easily fixed by moving the has_version
>> calls to pkg_preinst and storing the results in environment variab
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Carsten Lohrke wrote:
> On Dienstag, 9. September 2008, Jorge Manuel B. S. Vicetto wrote:
>> ~ * The meaning of the !atom blocker syntax now implies that
>> ~ temporary simultaneous installation of conflicting packages is
>> ~ allowed [3].
>>
>> ~
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Santiago M. Mola wrote:
> On Mon, Sep 15, 2008 at 9:45 PM, Vlastimil Babka <[EMAIL PROTECTED]> wrote:
>> I think it's better to prevent this rather than waste time with bug
>> reports like that. I asked Zac on IRC whether portage could filter such
>> f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Santiago M. Mola wrote:
> On Mon, Sep 15, 2008 at 9:45 PM, Vlastimil Babka <[EMAIL PROTECTED]> wrote:
>> I think it's better to prevent this rather than waste time with bug
>> reports like that. I asked Zac on IRC whether portage could filter such
>> f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vlastimil Babka wrote:
> Apparently, setting USE=x86 in make.conf on amd64 arch can have funny
> consequences such as [1]. And I can imagine even more subtle and hard to
> detect errors due to this.
>
> I think it's better to prevent this rather than
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ryan Hill wrote:
> If a file overwritten by the second package falls under CONFIG_PROTECT,
> will portage treat it like a normal update?
Yes, it's normal in the sense that the merge logic behaves exactly
the same as it would for any other merge. The m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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.
Please vote on deploying the PROPERTIES variable to the cache [1]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
Please consider a PROPERTIES=set value that allows an ebuild to
indicate that it should behave like a package set when selected on
the command line. This is behavior is somewhat difficult to describe
in words but the following example sho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donnie Berkholz wrote:
> On 09:19 Wed 17 Sep , Zac Medico wrote:
>> I suggest that we unmask the appropriate ARCH flags in
>> profiles/arch/*/use.mask, add ../base to profiles/arch/*/parent, and
>> create profiles/arch/base/us
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
> On Sat, 27 Sep 2008 17:21:18 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hi everyone,
>>
>> Please consi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Sun, 28 Sep 2008 10:42:39 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>> Some some sort of mapping of packages into sets space does seem
>> better than changing the behavior of these packages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Sat, 27 Sep 2008 17:21:18 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>> Does this seem like a good approach? Are there any suggestions for
>> improvements or alternative approaches?
>
&g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Sun, 28 Sep 2008 13:53:12 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>>>> Does this seem like a good approach? Are there any suggestions for
>>>> improvements or alternative approac
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Sun, 28 Sep 2008 15:11:42 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>>> GLEP 37 effectively abolishes virtuals. It doesn't try to overload
>>> new behaviour onto packages.
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Sun, 28 Sep 2008 15:56:27 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>> As I've tried to explain, the an ebuild which exhibits
>> PROPERTIES=set doesn't necessarily have to behave any
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rémi Cardona wrote:
> Zac Medico a écrit :
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hi everyone,
>>
>> Please consider a PROPERTIES=set value that allows an ebuild to
>> indicate that it s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan wrote:
> Zac Medico <[EMAIL PROTECTED]> posted [EMAIL PROTECTED],
> excerpted below, on Sun, 28 Sep 2008 15:56:27 -0700:
>
>> For example, `emerge kde-meta` would behave as as normal meta-package
>> currently
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bo Ørsted Andresen wrote:
> On Monday 29 September 2008 01:37:03 Zac Medico wrote:
>>> Why the need for multiple solutions at all? PROPERTIES=set is too weird
>>> and involves too much nonsensical behaviour to be useful.
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Long wrote:
> Zac Medico wrote:
>
>> Rémi Cardona wrote:
>>> Zac Medico a écrit :
>>>> Please consider a PROPERTIES=set value that allows an ebuild to
>>>> indicate that it should behave like a packa
1 - 100 of 1193 matches
Mail list logo
