put in that level of attention
every now and again when you're a developer?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
move media-plugins/mythgame media-plugins/mythplugins
> move media-plugins/mythmovies media-plugins/mythplugins
> move media-plugins/mythnews media-plugins/mythplugins
> move media-plugins/mythweather media-plugins/mythplugins
Nope.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ase.eclass,
> eutils.eclass and similar... we should probably move more functions
> there... :D
I'm not sure that having to make sure you don't break ten thousand
packages whenever you make a change is a good case... When it's EAPI
controlled, if a change causes problems, it doesn't break anything.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ising that the horse
has fled the barn and then trying to rationalise not needing a horse.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
nice hierarchy, and
you'd be expected to "override" variables like DESCRIPTION as you go
down the tree.
As it turns out, eclasses ended up being used in a completely different
way. But you still see bits of the original idea cropping up, such as
in the words "class" and "inherit" and "base".
--
Ciaran McCreesh
signature.asc
Description: PGP signature
S tough, but I doubt it.
With EAPI 5, LINGUAS will be intersected with IUSE (but with the
linguas_ bit stripped off).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
GUAS support for many
> autotools/gettext based packages, where the autotools code parses
> LINGUAS directly and the ebuild does nothing with it.
If there aren't any linguas_* flags in IUSE, LINGUAS should be empty,
and will be in future EAPIs. Without that, USE dependencies on
USE_EXPAND variables don't work.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 20 Jul 2012 12:39:21 -0400
Mike Gilbert wrote:
> On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
> wrote:
> > On Thu, 19 Jul 2012 18:34:41 -0400
> > Mike Gilbert wrote:
> >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico
> >> wrote:
> >> >
on-trivial". We're
not dealing with a small system here, so we need to move beyond "just
works (sort of)" to "correct". We can't provide people with the
features they're asking for without that.
> Perhaps we need to provide a cleaner way for ebuilds to specify if a
> given variable should be treated as a USE_EXPAND or not.
USE_EXPAND isn't a per ebuild setting.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
inally
known as 3. It's necessary to make use dependency defaults work
correctly for USE_EXPAND variables (which they currently do not, due to
it being omitted from what became EAPI 4).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 20 Jul 2012 13:55:46 -0400
Mike Gilbert wrote:
> On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
> wrote:
> > On Thu, 19 Jul 2012 18:34:41 -0400
> > Mike Gilbert wrote:
> >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico
> >> wrote:
> >> >
On Fri, 20 Jul 2012 14:09:28 -0400
Mike Gilbert wrote:
> Let me rephrase my question: If the user has not enabled any of the
> linguas flags via make.conf or package.use, will the LINGUAS variable
> be empty or unset in the ebuild environment?
Empty.
--
Ciaran McCreesh
sign
That's sensitive to old versions ebuilds being removed from the tree, so
it's utterly unworkable.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 20 Jul 2012 15:05:35 -0400
Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> On 20/07/12 01:54 PM, Ciaran McCreesh wrote:
> > On Fri, 20 Jul 2012 13:43:15 -0400 Alexandre Rostovtsev
> > wr
nder other ebuilds' dependencies
> unsatisfiable.
That's not how undefaulted use dependencies work. If wombat depends
upon foo[bar], it is an error if there is *any* version of foo *ever*
that doesn't have bar in IUSE_EFFECTIVE.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 20 Jul 2012 15:48:34 -0400
Alexandre Rostovtsev wrote:
> On Fri, 2012-07-20 at 20:17 +0100, Ciaran McCreesh wrote:
> > On Fri, 20 Jul 2012 15:15:31 -0400
> > Alexandre Rostovtsev wrote:
> > > > That's sensitive to old versions ebuilds being removed from t
On Fri, 20 Jul 2012 16:10:58 -0400
Alexandre Rostovtsev wrote:
> On Fri, 2012-07-20 at 21:02 +0100, Ciaran McCreesh wrote:
> > Which is why it's policy that you check every dependent before
> > making changes to a package. You *do* follow that policy, and not
> > just a
h him, he's a reasonable guy. If you suggest
that there's a possible alternative to a decision he's already made, or
that some of his justifications don't stand up to scrutiny, then he
ignores you.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
cular monolithic, vertically integrated, tightly
coupled way of doing things, and if you try to deviate from that way,
then you're stuffed.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
eclasses; changing inherit behaviour is just wallpapering over the
gaping hole.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 14 Aug 2012 22:54:13 +0200
Michał Górny wrote:
> On Tue, 14 Aug 2012 21:45:56 +0100
> Ciaran McCreesh wrote:
> > On Tue, 14 Aug 2012 11:44:49 +0200
> > Michał Górny wrote:
> > > As some of you may have noticed, lately introduced 'double include
> >
; > write huge eclasses that do more than one thing.
>
> And why? I believe we have quite a clean rule that *EAPI goes before
> inherit*.
That rule will only start applying from EAPI 6 onwards.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 14 Aug 2012 23:01:05 +0200
hasufell wrote:
> On 08/14/2012 10:56 PM, Ciaran McCreesh wrote:
> >
> > We can't change inherit behaviour in EAPI 5 anyway since it's a
> > global scope function, so I was planning to ignore it and hope that
> > by the time
On Tue, 14 Aug 2012 23:51:17 +0200
Michał Górny wrote:
> But you're aware that this 'reasonable approach' just made the whole
> problem by changing exported functions, right?
No, what made the whole problem is awful eclasses that do far too many
things.
--
Ciaran McC
at's going to be rather horrible when your package mangler
"temporarily" turns off acl or turns on build...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
re.
...an upgrade can result in the removal of two versions of a package,
not just one, if slots have changed.
It's thus much better to use REPLACING_VERSIONS (which is plural, and
this is important) rather than has_version, if you're asking about the
current package rather than another pac
ct rules for env saving with binary packages... We added
REPLACING_VERSIONS to make this kind of thing easy.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
it was Mike who was ignoring everyone else and
just doing whatever he wanted regardless of the consequences?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 27 Aug 2012 10:18:17 +0300
Samuli Suominen wrote:
> why leave the ebuild read $myconf from global scope? $EXTRA_ECONF
> works for this
As far as ebuilds are concerned, there is no such thing as EXTRA_ECONF.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 27 Aug 2012 12:01:28 +0300
Samuli Suominen wrote:
> On 27/08/12 10:25, Ciaran McCreesh wrote:
> > On Mon, 27 Aug 2012 10:18:17 +0300
> > Samuli Suominen wrote:
> >> why leave the ebuild read $myconf from global scope? $EXTRA_ECONF
> >> works for t
ng in "follow existing
policy" threads.
Simply put, developers are expected to follow the standard when
developing. If there's something people don't understand or would like
changed, it's entirely appropriate to talk about it as a separate issue,
but PMS cannot be ignored in the mean time.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 28 Aug 2012 00:19:28 +0200
Michał Górny wrote:
> + has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
Until EAPI 5 is available with support for IUSE_IMPLICIT, if you 'use
prefix', then prefix has to be listed in IUSE.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 29 Aug 2012 18:18:20 -0400
Mike Frysinger wrote:
> does it actually ? are DEPEND variables not allowed to be expanded in
> pkg_* src_* funcs ?
Nope. We don't guarantee that the metadata variable gets exported back
to the ebuild environment.
--
Ciaran McCreesh
si
nking that the fancy eclass-mangled
variables will have their mangled values visible within the environment.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
stall a package if you don't support its EAPI.
The "remove code" benefit applies to eclasses, not package manglers.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
we put fancy code in the package mangler to deal
with it?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
annoying things.
There are things we might change in future EAPIs that will in the very
long term make this discussion worthwhile. If we get rid of VDB access
or unconstrained env saving, *then* it might be worth having this
discussion.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
a lot of *DEPEND variables here... If we're
making people make major changes to their deps, which for HDEPEND we
definitely would be, then the "it's expensive since people would have
to redo their deps" argument against a combined DEPENDENCIES variable
goes out of the window, so we should rethink that too.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
; these is when ebuilds are shipped with PDEPENDs which are not required
> at runtime nor for cycle-breaking...
This is what we call "suggestions" and SDEPEND. There are already two
proposals for dealing with this general issue.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 31 Aug 2012 14:11:38 -0700
Zac Medico wrote:
> On 08/31/2012 01:46 PM, Ciaran McCreesh wrote:
> > On Fri, 31 Aug 2012 13:03:00 -0700
> > What exactly would the rules be for handling a package that is in
> > both DEPEND and HDEPEND, when ROOT is in effect? Woul
t
the viability of the idea...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
es that you want.
So does --take / --ignore with suggested dependencies, with the added
advantage that suggested packages don't end up being brought in without
user request just because a user has a particular use flag enabled
globally.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
tionals
> inside SDEPEND.
But you don't want to do that... The point of suggestions is that they
can be considered on their own merits.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 31 Aug 2012 18:45:59 -0700
Zac Medico wrote:
> On 08/31/2012 04:07 PM, Ciaran McCreesh wrote:
> > On Fri, 31 Aug 2012 16:03:25 -0700
> > Zac Medico wrote:
> >>> runtime-switchable USE flags for optional dependencies o.O? It
> >>> sounds li
e feature useful to users is to get the user
to explicitly accept or reject suggestions, and to make suggestions look
like suggestions.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
es will get
applied correctly now, and in a way visible to the package mangler, and
thus can be shown consistently in bug reports.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
think of EAPI 4 as being newer than EAPI 3. It's not fine for
you to consider EAPI 4 to be a superset of EAPI 3, and it's not fine to
try using comparisons other than string equality (with the annoying
special case for "" being "0") on an EAPI value.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
mentioned in the original post, and it
needs to be written up properly.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sun, 2 Sep 2012 20:46:19 +0200
Fabio Erculiani wrote:
> On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh
> wrote:
> > and we have worked out all the difficulties.
>
> Please elaborate. What difficulties? What did you implement other than
> plain SDEPEND? With what fea
On Sun, 2 Sep 2012 21:07:30 +0200
Michał Górny wrote:
> On Sun, 2 Sep 2012 19:08:33 +0100
> Ciaran McCreesh wrote:
> > On Sun, 2 Sep 2012 17:23:40 +0200
> > Michał Górny wrote:
> > > An effective SDEPEND implementation is definitely nowhere close
> > >
On Sun, 2 Sep 2012 21:38:26 +0200
Fabio Erculiani wrote:
> On Sun, Sep 2, 2012 at 9:04 PM, Ciaran McCreesh
> wrote:
> > On Sun, 2 Sep 2012 20:46:19 +0200
> > Fabio Erculiani wrote:
> >> On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh
> >> wrote:
&
r example, foo:1 and foo:2 both using
the same SCM repository, but different branches. Much as we'd like to
pretend that everyone uses Git, we can't really ignore this case...
So we have to decide: do we make the src_fetch copy the data somewhere
after all, or do we require that eclas
and run dependencies, the overall amount of
data to be processed in the common case that all dependencies are
required is smaller with unified DEPENDENCIES.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
problem; some (still) use subversion but will be migrated upstream
> soon(?).
>
> Other examples are libreoffice (main tree, git) and cups (main tree,
> subversion).
I guess that's a pretty comprehensive "we need to do this properly"
then.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
problem?
The problem is that we need to work out how to deal with this at least
for Subversion, and probably for CVS too... As much as we'd like to, we
can't just roll out a src_fetch without eclass changes. This doesn't
appear to be a trivial feature to provide.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
2) equals to O(n), because you don't know how that is
> going to be used in upper layers, today, tomorrow and in 5 years.
Uhm. O(n) == O(n/2). Anything assuming they're different is just wrong.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
his.
> Especially if it is python.eclass.
You know what the solution there is...
> And we will have to convert them back to old-style dependencies
> anyway. For the sake of compatibility with external tools.
No, external tools are required to be EAPI aware. If they're not, th
On Thu, 6 Sep 2012 09:39:25 +0200
Michał Górny wrote:
> On Thu, 6 Sep 2012 06:58:51 +0100
> Ciaran McCreesh wrote:
> > On Wed, 5 Sep 2012 18:15:43 +0200
> > Michał Górny wrote:
> > > If we really want to go this route, then please at least require
> > > exp
se? ( foo/bar )
>
> ?
Labels are propagated into child blocks, so it doesn't introduce a new
label. I think you've misunderstood something here...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
s by role rather than by fooness, then that's possible
too.
The rules for eclass merging need changing too, to add a ( ) around
values rather than merely appending. This is a technicality, and isn't
developer visible.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
understand what we're discussing, I'm afraid any contributions you make
will simply be shouting and waving.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 7 Sep 2012 16:23:16 +0200
Michał Górny wrote:
> On Fri, 7 Sep 2012 13:36:05 +0100
> Ciaran McCreesh wrote:
> > > These are the rules for a machine. People don't actually read
> > > dependencies sequentially. Provide a good algorithm which works
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 07 Sep 2012 10:50:40 -0400
Ian Stakenvicius wrote:
> On 07/09/12 07:45 AM, Ciaran McCreesh wrote:
> > [ Snip! ] Note also how the foo-related things, the bar-related
> > things etc cannot be grouped together by their foo
ot
a proper write-up, you can try reading it, understanding it and then
seeing if you have any objections to what's actually being proposed.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
e resolver,
though, so it may not be suitable for Gentoo.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 7 Sep 2012 12:28:31 -0400
Michael Mol wrote:
> An intermediate form of that might be useful for auditing the tree and
> finding packages which aren't expressing, e.g. RDEPENDS, but probably
> should.
RDEPEND=DEPEND was removed in EAPI 4, if that's what you mean.
s.
Uh, there is no "rewriting all existing ebuilds" anywhere. I've no idea
where you got that from...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 07 Sep 2012 09:53:46 -0700
Zac Medico wrote:
> If you're insinuating that Portage may not have a
> "fully-ROOT-and-/-aware resolver", then I can assure you that this is
> not a problem.
In that case, why do we need HDEPEND at all?
--
Ciaran McCreesh
signat
recompile of bar when libfnord in the same SLOT gets downgraded.
> (Because minors are used for compatible changes -- additions -- to the
> ABI.)
Downgrades aren't covered by sub-slots, slots, regular dependencies,
libtool, or anything else.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
DEPEND to TDEPEND. For this
> reason, the dominant preference was to go with HDEPEND.
They're looking at "minimum number of changes to make it appear to
work", not "minimum number of changes to express dependencies
correctly".
- --
Ciaran McCreesh
-BEGIN PGP SIGNATURE--
ibraries mostly.
"The part common with RDEPEND" is a different issue. We're talking
about what the usual thing to do is for dependencies that are in
DEPEND but not RDEPEND. A typical example here is a binary that is
executed as part of the build process.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
hen it comes to destinations, since RDEPEND
goes to ROOT.
The distinction between DEPEND and HDEPEND is relevant only for
dependencies that are not also in RDEPEND.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 7 Sep 2012 20:49:35 +0200
Fabian Groffen wrote:
> On 07-09-2012 19:21:57 +0100, Ciaran McCreesh wrote:
> > On Fri, 7 Sep 2012 20:17:17 +0200
> > Fabian Groffen wrote:
> > > Eh, no. Now it just always breaks when you perform a downgrade,
> > > and revdev
On Fri, 7 Sep 2012 21:11:22 +0200
Michał Górny wrote:
> On Fri, 7 Sep 2012 19:52:05 +0100
> Ciaran McCreesh wrote:
> > On Fri, 7 Sep 2012 20:46:48 +0200
> > Michał Górny wrote:
> > > Now, let me remind you because you probably fail to know the world
&g
not most of them will become HDEPENDs, if dependencies are
being expressed properly. If that is the case, then it makes more sense
to introduce TDEPEND than HDEPEND.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
eds dep:1/a. However, a clever dependency
resolver can note that reinstalling pkg would fix it, since dep:1/b
also satisfies pkg's slot 1 := dependency (but not the locked 1/a
dependency that the installed version of pkg has picked up).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
e more than a handful of very
special cases that would be covered by the second point. Can anyone
provide examples?
- --
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlBKVbQACgkQ96zL6DUtXhHcUwCfdNq3MSMyYBAx19ImoOtWFMRM
l2UAoM6DfYJOCL4tLwZ3s6Jeh/6CzBCI
=FIrN
-END PGP SIGNATURE-
On Fri, 7 Sep 2012 22:07:30 +0200
Michał Górny wrote:
> On Fri, 7 Sep 2012 20:25:58 +0100
> Ciaran McCreesh wrote:
> > On Fri, 7 Sep 2012 21:21:42 +0200
> > Michał Górny wrote:
> > > So... what is your issue in here, sir?
> >
> > The issue is what Zac
Is it because $ROOT/var/cache/fontconfig needs to exist at build
time, but not at runtime? If so, is this better fixed by using a
temporary directory?
> Bug 317337 (original HDEPEND proposal) mentions the
> x11-proto/xcb-proto dep for libxcb (and i assume anything else
> depending
On Fri, 07 Sep 2012 18:55:10 -0400
Michael Orlitzky wrote:
> I think that dependencies are ultimately not hierarchical
Situations like foo? ( bar? ( || ( a ( b c ) ) ) ) do happen, so any
new syntax would have to be able to deal with that.
--
Ciaran McCreesh
signature.asc
Description:
package.mask and later remove.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
y we should just not support prefix at all in any EAPI before
5, and not have the whole "but define those prefix variables anyway"
hack in eclasses. But apparently people are preferring to go to great
lengths not to have to use newer EAPIs...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 10 Sep 2012 11:25:05 +0200
Fabian Groffen wrote:
> On 10-09-2012 09:32:23 +0100, Ciaran McCreesh wrote:
> > So really we should just not support prefix at all in any EAPI
> > before 5, and not have the whole "but define those prefix variables
> > anyway" h
#x27;t
> impact anything in gentoo-x86, nor any tree I've ever seen.
No crack pipe was involved in that decision! It's because of LINGUAS.
(Incidentally, we used : rather than @ for separation for exheres-0 for
that reason.)
--
Ciaran McCreesh
signature.asc
Description: PGP signature
inherit line are EAPI and any
variables used by eclasses to determine behaviour.
- --
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlBTmfcACgkQ96zL6DUtXhGzDgCcCn6mOes+8eswLl58ba6CBX4v
MisAoLNLzGivS6pDZHDF4YZv2poAY7K/
=/5qc
-END PGP SIGNATURE-
that we have := slot
dependencies.
Ultimately, it comes down to the observation that the flag? ( ) syntax
is strongly nested and hierarchical, but dependency roles aren't.
Labels can give all the advantages of your proposal (including the
backwards compatibility, if that's desired), but without the need to
shoehorn the idea into an unsuitable syntax.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
t;
> If you want your proposal to go anywhere, you're going to need a
> better transition plan then "and then devs convert their
> ebuilds/eclasses". I'd suggested it prior, but no traction there.
Your "rewrite *DEPEND" approach can just as easily be used with labels.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 17 Sep 2012 00:58:02 -0700
"Gregory M. Turner" wrote:
> Unless I'm missing something, it seems that once we deprive the
> ebuild developer of this feature, there is no simple, supported way
> to retrieve the information except to depend on it.
has_versi
, with
considerable overlap between them all.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 17 Sep 2012 21:48:07 +0800
Ben de Groot wrote:
> On 17 September 2012 20:41, Ciaran McCreesh
> wrote:
> > On Mon, 17 Sep 2012 19:49:12 +0800
> > Ben de Groot wrote:
> >> Or, even easier and more straightforward: just keep using *DEPEND.
> >> The case
thy explanation that started
this thread, then.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
t; is what I would like to do for the experimental EAPI 5-hdepend which
> is planned [1].
What're we going to do about the zillions of unsolvable cycles that
that would create? (Does Portage detect those and error out yet?)
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 18 Sep 2012 12:40:51 -0700
Zac Medico wrote:
> On 09/18/2012 12:29 PM, Ciaran McCreesh wrote:
> > On Tue, 18 Sep 2012 12:25:57 -0700
> > Zac Medico wrote:
> >> Also, if we change the meaning of RDEPEND in the next EAPI, so that
> >> it's a hard b
On Tue, 18 Sep 2012 12:58:30 -0700
Zac Medico wrote:
> On 09/18/2012 12:44 PM, Ciaran McCreesh wrote:
> > On Tue, 18 Sep 2012 12:40:51 -0700
> > Zac Medico wrote:
> >> On 09/18/2012 12:29 PM, Ciaran McCreesh wrote:
> >>> On Tue, 18 Sep 2012 12:25:57 -0700
>
On Tue, 18 Sep 2012 22:06:06 +0200
Michał Górny wrote:
> So far, I'm not sure if there was a single, complete, exact problem
> discussed which is solved by this syntax other than cosmetics.
Perhaps you should read the GLEP then.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 18 Sep 2012 22:22:56 +0200
Michał Górny wrote:
> On Tue, 18 Sep 2012 21:11:10 +0100
> Ciaran McCreesh wrote:
> > On Tue, 18 Sep 2012 22:06:06 +0200
> > Michał Górny wrote:
> > > So far, I'm not sure if there was a single, complete, exact
> > >
On Tue, 18 Sep 2012 22:51:04 +0200
Michał Górny wrote:
> On Tue, 18 Sep 2012 20:44:33 +0100
> Ciaran McCreesh wrote:
> > On Tue, 18 Sep 2012 12:40:51 -0700
> > Zac Medico wrote:
> > > On 09/18/2012 12:29 PM, Ciaran McCreesh wrote:
> > > > On Tue, 18 Sep
of RDEPENDs are ignorable.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 18 Sep 2012 23:34:29 +0200
Michał Górny wrote:
> On Tue, 18 Sep 2012 22:08:43 +0100
> Ciaran McCreesh wrote:
> > On Tue, 18 Sep 2012 23:06:06 +0200
> > Michał Górny wrote:
> > > But didn't we already point out that we can't have them in RDEPEND
On Wed, 19 Sep 2012 00:01:21 +0200
Michał Górny wrote:
> On Tue, 18 Sep 2012 22:37:19 +0100
> Ciaran McCreesh wrote:
> > On Tue, 18 Sep 2012 23:34:29 +0200
> > Michał Górny wrote:
> > > On Tue, 18 Sep 2012 22:08:43 +0100
> > > Ciaran McCreesh wrote:
> &
1301 - 1400 of 3510 matches
Mail list logo
