Peter Volkov wrote:
> This means that every ebuild which uses 'unpack ${A}' should have in
> DEPEND a program which is selected by filename extension of sources. So
> as I understood your initial suggestion was to make this happen
> automatically. And this is very logical as makes ebuilds cleaner a
On Sun, 20 Jul 2008 17:41:58 +0400
Peter Volkov <[EMAIL PROTECTED]> wrote:
> В Чтв, 17/07/2008 в 04:51 +0200, Marius Mauch пишет:
> > At dev.gentoo.org/~genone/unpack.eclass is the draft for an eclass
> > to implement this feature.
>
> Marius, although it's possible to do this things in eclass
В Чтв, 17/07/2008 в 04:51 +0200, Marius Mauch пишет:
> At dev.gentoo.org/~genone/unpack.eclass is the draft for an eclass
> to implement this feature.
Marius, although it's possible to do this things in eclass why is eclass
better? As I see portage's unpack() already has extension <-> "program
t
Marius Mauch kirjoitti:
If someone wants to use it I can add it on the tree (after the normal
review process and being better tested), but I'll only be doing it
when there is an actual demand for it (no point in adding an eclass that
nobody uses).
I have been long thinking about adding suppor
On Thu, 17 Jul 2008 07:00:32 -0500
Joe Peterson <[EMAIL PROTECTED]> wrote:
> Marius Mauch wrote:
> > The eclass also contains it's own implementation of unpack (renamed
> > to unpack2) and src_unpack so the logic which tools/packages are
> > used for unpacking can be maintained in a single place i
Marius Mauch wrote:
> The eclass also contains it's own implementation of unpack (renamed to
> unpack2) and src_unpack so the logic which tools/packages are used for
> unpacking can be maintained in a single place instead of being
> splitted between the package manager and the tree.
Marius, these
On Tue, 15 Jul 2008 04:14:18 +0200
Marius Mauch <[EMAIL PROTECTED]> wrote:
> As a result of Cardoes earlier mail we talked a bit about possible
> solutions in #gento-portage, and I suggested to let portage
> automatically inject the deps based on SRC_URI pattern matching.
> A mapping of extensions
On Wed, 16 Jul 2008 00:43:28 +0200
Marius Mauch <[EMAIL PROTECTED]> wrote:
> Interesting idea. Unfortunately our depstring parser doesn't like
> empty parentheses (as they are usually problem indicators), so it
> doesn't work out.
Bleh. You can hack around that using a second (looping) pass then.
On Tue, 15 Jul 2008 22:34:33 +0100
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> On Tue, 15 Jul 2008 23:23:26 +0200
> Marius Mauch <[EMAIL PROTECTED]> wrote:
> > Right, just I'd expect the parsing of SRC_URI (with conditionals) to
> > be a bit tricky in bash, not something I'm going to work on. An
On Tue, 15 Jul 2008 23:23:26 +0200
Marius Mauch <[EMAIL PROTECTED]> wrote:
> Right, just I'd expect the parsing of SRC_URI (with conditionals) to
> be a bit tricky in bash, not something I'm going to work on. An
> eclass-based solution would have a few benefits though wrt the
> metadata cache.
Wel
On Tue, 15 Jul 2008 19:12:37 +0100
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> On Tue, 15 Jul 2008 04:14:18 +0200
> Marius Mauch <[EMAIL PROTECTED]> wrote:
> > As a result of Cardoes earlier mail we talked a bit about possible
> > solutions in #gento-portage, and I suggested to let portage
> > au
If an ebuild lists bzip2 in DEPEND, the package manager has to bring it in.
The proposed method would only add automatically determined dependencies, not
remove what you listed in DEPEND.
A hypothetical problem is; If a package source file has a bz extension but does
not need bzip2 in any way,
On Tue, 15 Jul 2008 22:15:16 +0300
Petteri Räty <[EMAIL PROTECTED]> wrote:
> > Could do it just as an eclass...
> >
> > inherit work-out-my-unpack-deps-for-me
> >
> > In principle, there's nothing that can't be done on the ebuild side
> > here.
>
> Wouldn't this also require having a variable li
Ciaran McCreesh kirjoitti:
On Tue, 15 Jul 2008 04:14:18 +0200
Marius Mauch <[EMAIL PROTECTED]> wrote:
As a result of Cardoes earlier mail we talked a bit about possible
solutions in #gento-portage, and I suggested to let portage
automatically inject the deps based on SRC_URI pattern matching.
A
Ciaran McCreesh wrote:
On Tue, 15 Jul 2008 04:14:18 +0200
Marius Mauch <[EMAIL PROTECTED]> wrote:
As a result of Cardoes earlier mail we talked a bit about possible
solutions in #gento-portage, and I suggested to let portage
automatically inject the deps based on SRC_URI pattern matching.
A m
Fabian Groffen wrote:
Manual override as in "emerge --nodeps" or something.
No, manual override as in "the ebuild turns off auto-detection and
specifically asks for app-arch/{bzip2,gzip,tar,whatever} using DEPEND"
Cheers,
Rémi
--
gentoo-dev@lists.gentoo.org mailing list
On Tue, 15 Jul 2008 04:14:18 +0200
Marius Mauch <[EMAIL PROTECTED]> wrote:
> As a result of Cardoes earlier mail we talked a bit about possible
> solutions in #gento-portage, and I suggested to let portage
> automatically inject the deps based on SRC_URI pattern matching.
> A mapping of extensions
On 15-07-2008 19:53:47 +0200, Rémi Cardona wrote:
> Marius Mauch wrote:
>> Potential problems:
>> - might cause trouble for some packages that use custom code for
>> unpacking, or due to circular deps, this could simply be solved with a
>> new RESTRICT value though.
>
> As long as this is done to a
Marius Mauch wrote:
Potential problems:
- might cause trouble for some packages that use custom code for
unpacking, or due to circular deps, this could simply be solved with a
new RESTRICT value though.
As long as this is done to allow a 100% manual override, then this is a
_very_ good idea.
Marius Mauch kirjoitti:
So, is this something ebuild maintainers would like in general, or does
such a feature cause you nightmares?
I have actually been thinking about writing support for this into the
Java eclasses because most Java upstreams use .zip files and we need
app-arch/unzip in D
Marius Mauch wrote:
As a result of Cardoes earlier mail we talked a bit about possible
solutions in #gento-portage, and I suggested to let portage
automatically inject the deps based on SRC_URI pattern matching.
A mapping of extensions and their unpack deps would be kept in the tree
(e.g. mapping
As a result of Cardoes earlier mail we talked a bit about possible
solutions in #gento-portage, and I suggested to let portage
automatically inject the deps based on SRC_URI pattern matching.
A mapping of extensions and their unpack deps would be kept in the tree
(e.g. mapping '.tar.bz2' to '( app-
22 matches
Mail list logo
