On Mon, Oct 3, 2016 at 1:53 PM, Kent Fredric wrote:
> And I get the impression that the desire you have to have different
> behaviour for non-rc versions is a bit niche.
Not quite. I just started by siding with the current implementation
which is to disable system readline in rc versions of bash
On Mon, 3 Oct 2016 13:32:34 +0800
konsolebox wrote:
> "A useflag that entirely goes away depending on the version" (or a
> flag that is implemented in one ebuild but is not on another) is
> pretty common among packages and I see that as totally valid, and is
> way better than a solution that uses
On Mon, Oct 3, 2016 at 1:37 PM, konsolebox wrote:
> I created another example for this.
I mistakenly renamed --with-installed-readline to
--with-system-readline there, sorry. Here's the correct one.
--
konsolebox
bash-4.4-r1.ebuild
Description: Binary data
I examined both RC versions of bash and readline, and it turns out
that the KEYWORDS are disabled in those. If that is -always- the
case, we could just have IUSE='+system-readline' in any version
regardless if it's a release or not, since users would not be able to
install it anyway, unless they a
On Sun, Oct 2, 2016 at 7:42 PM, Kent Fredric wrote:
> On Sun, 2 Oct 2016 18:18:17 +0800
> konsolebox wrote:
>
>> I should also add that a dynamic "default" that varies depending on
>> the version doesn't sound good to me. For one at least, it confuses
>> the user.
>
> I agree that its a bit unint
On 02/10/16 04:59 PM, James Le Cuirot wrote:
> On Sun, 2 Oct 2016 21:48:04 +0100
> James Le Cuirot wrote:
>
>> SRC_URI="gogdownloader://tomb_raider_1/en1installer1 ->
>> setup_tomb_raider_${PV}.exe" IUSE="gogdownloader"
>> RESTRICT="!gogdownloader? ( fetch ) mirror"
>> DEPEND="games-util/lgogdown
On 10/02/2016 01:48 PM, James Le Cuirot wrote:
> Hi guys,
>
> As the newest member of the games team, I've had a somewhat
> off-the-wall idea. Like many gamers, I have a sizeable collection of
> games purchased from GOG.com. There have been efforts to package some
> of these, mainly in overlays, a
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2016-10-02 23:59 UTC.
Removals:
app-admin/389-admin-console20161001-08:00 pacho 755e2e7
app-admin/389-ds-console 20161001-08:00 pacho 755e2e7
app-admin/logs
On Sun, Oct 2, 2016 at 3:48 PM, James Le Cuirot wrote:
> So wouldn't it be great if Portage could handle these gogdownloader://
> URLs?
Yes, it would. But it's just a symptom of the fetching system being
inadequate. I gave up on overhauling the git eclasses and a few other
things for the same rea
On Sun, 2 Oct 2016 21:48:04 +0100
James Le Cuirot wrote:
> Other than that, I'm just looking for feedback. Please be kind. This is
> very much opt-in via the gogdownloader flag so if you don't have any
> major technical qualms with it, don't spoil the fun. :)
Please open a 'Future EAPI' bug, so
On Sun, 2 Oct 2016 21:48:04 +0100
James Le Cuirot wrote:
> SRC_URI="gogdownloader://tomb_raider_1/en1installer1 ->
> setup_tomb_raider_${PV}.exe" IUSE="gogdownloader"
> RESTRICT="!gogdownloader? ( fetch ) mirror"
> DEPEND="games-util/lgogdownloader"
Probably goes without saying but that should h
Hi guys,
As the newest member of the games team, I've had a somewhat
off-the-wall idea. Like many gamers, I have a sizeable collection of
games purchased from GOG.com. There have been efforts to package some
of these, mainly in overlays, and I'd like to see more in the tree.
There are basically 3
On Sat, 1 Oct 2016 00:48:52 +0200
Kristian Fiskerstrand wrote:
> > However I *want* the message to be loud and obnoxious.
> > We need eblinkwarn ... :o)
> >
>
> I don't see why users should be bothered with maintainer mistakes that
> doesn't affect them (in this particular circumstance)
Soun
On Sun, Sep 25, 2016 at 5:05 AM, James Le Cuirot wrote:
> Now I remember why I couldn't rely on bashrc for this.
> elibtoolize comes from the libtool eclass and you can't inherit
> additional eclasses from bashrc.
This is what I'm dealing with all the time. It would be easier if
eclasses weren't
On Sun, 2 Oct 2016 18:18:17 +0800
konsolebox wrote:
> I should also add that a dynamic "default" that varies depending on
> the version doesn't sound good to me. For one at least, it confuses
> the user.
I agree that its a bit unintuitive.
However, the alternatives are:
- A useflag that entir
On Sun, Oct 2, 2016 at 6:00 PM, konsolebox wrote:
> On Sun, Oct 2, 2016 at 4:58 PM, Kent Fredric wrote:
>> On Sun, 2 Oct 2016 16:03:11 +0800
>> konsolebox wrote:
>>
>>> I actually don't like the idea of enabling or disabling
>>> "installed-readline" based on the `${PV} != *_rc*` condition. If a
On Sun, Oct 2, 2016 at 4:58 PM, Kent Fredric wrote:
> On Sun, 2 Oct 2016 16:03:11 +0800
> konsolebox wrote:
>
>> I actually don't like the idea of enabling or disabling
>> "installed-readline" based on the `${PV} != *_rc*` condition. If a
>> user would want to explicitly enable "installed-readli
On Sun, 2 Oct 2016 16:03:11 +0800
konsolebox wrote:
> I actually don't like the idea of enabling or disabling
> "installed-readline" based on the `${PV} != *_rc*` condition. If a
> user would want to explicitly enable "installed-readline" globally,
> how would he make sure that it only affects t
On Sun, Oct 2, 2016 at 1:40 PM, Kent Fredric wrote:
> On Sun, 2 Oct 2016 13:28:04 +0800
> konsolebox wrote:
>
>> I guess that's another good way to solve the readline issue (when it
>> comes to bash). But I'd prefer that it's not done automatically.
>> Instead we should add a formal use flag lik
On Sun, 2 Oct 2016 13:28:04 +0800
konsolebox wrote:
> I guess that's another good way to solve the readline issue (when it
> comes to bash). But I'd prefer that it's not done automatically.
> Instead we should add a formal use flag like 'installed-readline'. We
> can add it to release versions
20 matches
Mail list logo
