-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kent Fredric wrote:
Ok, I've re-thought some of my ideas and tried to come up with a more
concise explanation
with some practical example syntax. The basic concept of 'check' was
'this will work even if the package aint installed yet' and info
often times when i get a bug report about certain packages, there's
information about that package that i usually ask for ... i wonder if this
can be automated
perhaps extend the syntax of profiles/info_pkgs:
atom [command to pass to system()]
sys-libs/glibc /lib/libc.so.6
then when people run
Mike Frysinger kirjoitti:
often times when i get a bug report about certain packages, there's
information about that package that i usually ask for ... i wonder if this
can be automated
perhaps extend the syntax of profiles/info_pkgs:
atom [command to pass to system()]
sys-libs/glibc
On Sat, 7 Jul 2007 17:43:44 -0400
Mike Frysinger [EMAIL PROTECTED] wrote:
often times when i get a bug report about certain packages, there's
information about that package that i usually ask for ... i wonder if
this can be automated
perhaps extend the syntax of profiles/info_pkgs:
atom
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
5) considering 3), I'd rather see such information be specified by
ebuilds somehow, not a global file (think about overlays). Maybe by
installing a script in a specific location or so.
Marius
How about adding another function
On Saturday 07 July 2007, Kevin Lacquement wrote:
Marius Mauch wrote:
5) considering 3), I'd rather see such information be specified by
ebuilds somehow, not a global file (think about overlays). Maybe by
installing a script in a specific location or so.
How about adding another function
On 7/8/07, Kevin Lacquement [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
5) considering 3), I'd rather see such information be specified by
ebuilds somehow, not a global file (think about overlays). Maybe by
installing a script in a specific
On Saturday 07 July 2007, Kent Fredric wrote:
Implementation details wise, I would like to see packages have
possibly 2 functions,
1: Info, and 2: Check.
Reason Being that you wont be able to fetch installation status info
on a package thats not installed, and if a package is failing to
On 7/8/07, Mike Frysinger [EMAIL PROTECTED] wrote:
On Saturday 07 July 2007, Kent Fredric wrote:
Implementation details wise, I would like to see packages have
possibly 2 functions,
1: Info, and 2: Check.
Reason Being that you wont be able to fetch installation status info
on a package
On Saturday 07 July 2007, Kent Fredric wrote:
On 7/8/07, Mike Frysinger [EMAIL PROTECTED] wrote:
On Saturday 07 July 2007, Kent Fredric wrote:
Implementation details wise, I would like to see packages have
possibly 2 functions,
1: Info, and 2: Check.
Reason Being that you wont be
On 7/8/07, Mike Frysinger [EMAIL PROTECTED] wrote:
On Saturday 07 July 2007, Kent Fredric wrote:
On 7/8/07, Mike Frysinger [EMAIL PROTECTED] wrote:
On Saturday 07 July 2007, Kent Fredric wrote:
Implementation details wise, I would like to see packages have
possibly 2 functions,
1:
On Sunday 08 July 2007, Kent Fredric wrote:
Ok, I've re-thought some of my ideas and tried to come up with a more
concise explanation
with some practical example syntax. The basic concept of 'check' was
'this will work even if the package aint installed yet' and info was
'for working but bust
On 7/8/07, Mike Frysinger [EMAIL PROTECTED] wrote:
On Sunday 08 July 2007, Kent Fredric wrote:
Ok, I've re-thought some of my ideas and tried to come up with a more
concise explanation
with some practical example syntax. The basic concept of 'check' was
'this will work even if the package
13 matches
Mail list logo
