On Sun, 2011-04-24 at 00:17 +0200, Michał Górny wrote:
> Hello,
>
> Just a quick RFC. With the bugzie migration, the quick search has been
> extended to grep over bug contents. This makes this handy search real
> slow and not really useful (due to a lot of useless results).
>
> I personally type
On Sun, Apr 24, 2011 at 07:39:55AM +0200, Ulrich Mueller wrote:
> I can live with that, as long as the responsibility that packages work
> with dependencies from overlays stays entirely with the overlay's
> maintainer.
Good point. Agreed.
> But could you please add a comment in the virtual's ebu
> On Sun, 24 Apr 2011, Eray Aslan wrote:
> The consensus seems to be to leave it for the package maintainer to
> decide.
> I, for one, will be making the necessary changes to include packages
> from overlays until, for whatever reason, it either
> * becomes too burdensome
> * hinders the mai
Replying randomly
On Sat, Apr 23, 2011 at 08:24:59AM -0700, Zac Medico wrote:
The consensus seems to be to leave it for the package maintainer to
decide.
I, for one, will be making the necessary changes to include packages
from overlays until, for whatever reason, it either
* becomes too burden
On 04/24/2011 12:17 AM, Michał Górny wrote:
> Hello,
>
> Just a quick RFC. With the bugzie migration, the quick search has been
> extended to grep over bug contents. This makes this handy search real
> slow and not really useful (due to a lot of useless results).
>
> I personally type in 'summary
Hello,
Just a quick RFC. With the bugzie migration, the quick search has been
extended to grep over bug contents. This makes this handy search real
slow and not really useful (due to a lot of useless results).
I personally type in 'summary:' there every time I use it, and AFAIK
I'm not the only d
Ciaran McCreesh schrieb:
> On Sat, 23 Apr 2011 16:47:37 +0200
> Chí-Thanh Christopher Nguyễn wrote:
>
>> What I propose solves the problems that old-style virtuals introduce
>> in dependency resolution.
>>
> Not really, because it means we'd have to keep the nasty old code around
> forever
> On Sat, 23 Apr 2011, Ciaran McCreesh wrote:
> On Sat, 23 Apr 2011 16:47:37 +0200
> Chí-Thanh Christopher Nguyễn wrote:
>> What I propose solves the problems that old-style virtuals
>> introduce in dependency resolution. What other problems do they
>> cause?
> DEPEND=">=virtual/blah-2"
> D
On 04/23/2011 06:05 AM, Ulrich Mueller wrote:
>> On Sat, 23 Apr 2011, Thomas Sachau wrote:
>
>> If e.g. kde and sunrise overlay both provide an mta, they would both
>> need a fork of virtual/mta. Now one of those forks will be preferred
>> and used, e.g. the kde one. This means, that you canno
On Sat, 23 Apr 2011 16:47:37 +0200
Chí-Thanh Christopher Nguyễn wrote:
> What I propose solves the problems that old-style virtuals introduce
> in dependency resolution.
Not really, because it means we'd have to keep the nasty old code around
forever. If we just do away with the things entirely i
Ciaran McCreesh schrieb:
> On Sat, 23 Apr 2011 15:28:04 +0200
> Chí-Thanh Christopher Nguyễn wrote:
>
>> Because there is a reason for not doing so, or because you think that
>> multi-repository support is a superior solution which will come
>> sooner?
>>
> Because what you propose solves
On Sat, 23 Apr 2011 15:28:04 +0200
Chí-Thanh Christopher Nguyễn wrote:
> Because there is a reason for not doing so, or because you think that
> multi-repository support is a superior solution which will come
> sooner?
Because what you propose solves nothing, and prevents the entire point
of the
Ciaran McCreesh schrieb:
> On Sat, 23 Apr 2011 12:28:29 +0200
> Chí-Thanh Christopher Nguyễn wrote:
>
>> Would it make sense to do the following:
>> (1) make all new-style virtuals additionally depend on an old-style
>> virtual (a new category might be appropriate)
>>
> No.
>
Because t
Zac Medico schrieb:
>> Would it make sense to do the following:
>> (1) make all new-style virtuals additionally depend on an old-style
>> virtual (a new category might be appropriate)
>> (2) ebuilds in overlays can PROVIDE the old-style virtual
>>
> It seems like new-style virtual would be int
William Hubbs schrieb:
> I'm not an overlay user, but I'm thinking that an overlay user might be
> able to get around this by putting the virtual in package.provided.
>
Why must the user do it? Can't the package manager do it?
Regards,
Chi-Thanh Christopher Nguyen
> On Sat, 23 Apr 2011, Thomas Sachau wrote:
> If e.g. kde and sunrise overlay both provide an mta, they would both
> need a fork of virtual/mta. Now one of those forks will be preferred
> and used, e.g. the kde one. This means, that you cannot install the
> mta from sunrise to satisfy the virt
On Sat, 23 Apr 2011 14:07:21 +0200
Thomas Sachau wrote:
> It may be no issue as long as the virtual does not change that much
> or as long as not more than 1 overlay forks the virtual. But as
> already written in Bugzilla, you create an issue for users, if you
> have 2 overlays added, which both p
Am 23.04.2011 13:02, schrieb Zac Medico:
> On 04/22/2011 11:05 PM, Eray Aslan wrote:
>> On the other hand, we are making life (unneccesarily?) difficult for
>> overlay users by not incorporating the requested changes to the official
>> tree.
>
> I don't imagine it's that much work to maintain a fo
Am 23.04.2011 08:05, schrieb Eray Aslan:
> https://bugs.gentoo.org/show_bug.cgi?id=364445
> https://bugs.gentoo.org/show_bug.cgi?id=364401
>
> Basically, there are requests to add packages to RDEPEND in virtual/mda
> and virtual/mta that are not in the official tree but in sunrise.
>
> On one sid
On Sat, Apr 23, 2011 at 04:02:24AM -0700, Zac Medico wrote:
> On 04/22/2011 11:05 PM, Eray Aslan wrote:
> > https://bugs.gentoo.org/show_bug.cgi?id=364445
> > https://bugs.gentoo.org/show_bug.cgi?id=364401
> >
> > Basically, there are requests to add packages to RDEPEND in virtual/mda
> > and virt
On Sat, 23 Apr 2011 09:05:48 +0300
Eray Aslan wrote:
> Comments on how to proceed? Is it OK for a virtual to list a package
> which is in an overlay in RDEPEND?
The way || ( ) dependencies are defined means doing so doesn't cause
any problems.
Having said that, overlays can always supply their
On Sat, 23 Apr 2011 12:28:29 +0200
Chí-Thanh Christopher Nguyễn wrote:
> Would it make sense to do the following:
> (1) make all new-style virtuals additionally depend on an old-style
> virtual (a new category might be appropriate)
No.
--
Ciaran McCreesh
signature.asc
Description: PGP signatu
Masked for removal in 30 days. The last release was 2007 and there better
alternatives for every toolkit (chmsee (gtk), kchmviewer (qt), xchm (wxGTK)).
--
fonts, gcc-porting, it makes no sense how it makes no sense
toolchain, wxwidgets but i'll take it
On 04/23/2011 03:28 AM, Chí-Thanh Christopher Nguyễn wrote:
> Eray Aslan schrieb:
>> https://bugs.gentoo.org/show_bug.cgi?id=364445
>> https://bugs.gentoo.org/show_bug.cgi?id=364401
>>
>> Basically, there are requests to add packages to RDEPEND in virtual/mda
>> and virtual/mta that are not in the
Il giorno sab, 23/04/2011 alle 09.05 +0300, Eray Aslan ha scritto:
>
> On one side, *DEPENDing on a package outside the tree doesn't seem
> right. Additionally, keeping track of all the overlays and their
> package versions, USE flags and flag changes are potentially too much
> to
> track. We wi
On Sat, Apr 23, 2011 at 09:05:48AM +0300, Eray Aslan wrote:
> https://bugs.gentoo.org/show_bug.cgi?id=364445
> https://bugs.gentoo.org/show_bug.cgi?id=364401
>
> Basically, there are requests to add packages to RDEPEND in virtual/mda
> and virtual/mta that are not in the official tree but in sunri
On 04/22/2011 11:05 PM, Eray Aslan wrote:
> https://bugs.gentoo.org/show_bug.cgi?id=364445
> https://bugs.gentoo.org/show_bug.cgi?id=364401
>
> Basically, there are requests to add packages to RDEPEND in virtual/mda
> and virtual/mta that are not in the official tree but in sunrise.
>
> On one si
Eray Aslan schrieb:
> https://bugs.gentoo.org/show_bug.cgi?id=364445
> https://bugs.gentoo.org/show_bug.cgi?id=364401
>
> Basically, there are requests to add packages to RDEPEND in virtual/mda
> and virtual/mta that are not in the official tree but in sunrise.
>
> On one side, *DEPENDing on a pack
28 matches
Mail list logo
