On Thu, 2005-10-27 at 09:40 -0400, Olivier Crête wrote:
> On Thu, 2005-27-10 at 09:36 +0200, Paul de Vrieze wrote:
> > On Thursday 27 October 2005 02:15, Luca Barbato wrote:
> > > Paul de Vrieze wrote:
> > > > In the case of embedded it is clear that what in binary distributions
> > > > is part of
On Thu, 2005-27-10 at 09:36 +0200, Paul de Vrieze wrote:
> On Thursday 27 October 2005 02:15, Luca Barbato wrote:
> > Paul de Vrieze wrote:
> > > In the case of embedded it is clear that what in binary distributions
> > > is part of the development package (.la files, static libraries,
> > > header
On Thursday 27 October 2005 02:15, Luca Barbato wrote:
> Paul de Vrieze wrote:
> > I agree here. If you don't want packages to be pulled in because of
> > header files, you need support for that (perhaps in the form of
> > subpackages, or a useflag). But IF the header files of a package are
> > ins
Paul de Vrieze wrote:
I agree here. If you don't want packages to be pulled in because of header
files, you need support for that (perhaps in the form of subpackages, or
a useflag). But IF the header files of a package are installed one should
be able to assume that they keep on working. Even
On Tuesday 25 October 2005 18:55, Grant Goodyear wrote:
> > Maybe for some people compiling is included in runtime, but I'm not
> > one of them.
>
> I am. I frequently compile software against installed libraries in my
> day job. I don't run into this problem solely because I don't install
> bina
On Tuesday 25 October 2005 22:38, Ciaran McCreesh wrote:
> On Tue, 25 Oct 2005 16:05:00 -0400 solar <[EMAIL PROTECTED]> wrote:
> | You two are the ones trying to distort the meaning of RDEPEND=
> | simply because the depclean is broken for the cases you make.
>
> Not at all. The 'R' in RDEPEND mean
On Tuesday 25 October 2005 07:18, Ned Ludd wrote:
> > Now, the other side of the story. It's not true runtime dependence
> > because it's not required for programs to run, only to compile. And
> > the way I see it, things required for programs to compile are by
> > definition DEPEND rather than RD
On Tuesday 25 October 2005 08:01, Spider (D.m.D. Lj.) wrote:
>
> actually, I'm not in agreement here. If I install libfoo, be it from
> binaries or source, I certainly expect to be able to use libfoo, and
> that includes being able to build software against it, things I work
> on myself, other sou
On Tue, 25 Oct 2005 16:05:00 -0400 solar <[EMAIL PROTECTED]> wrote:
| You two are the ones trying to distort the meaning of RDEPEND=
| simply because the depclean is broken for the cases you make.
Not at all. The 'R' in RDEPEND means 'needed after the compile is
done'. However, for the sake of ke
On Tue, 2005-10-25 at 20:16 +0100, Ciaran McCreesh wrote:
> On Tue, 25 Oct 2005 13:55:36 -0400 solar <[EMAIL PROTECTED]> wrote:
> | Please do not put words in my mouth. I've already asserted to you
> | several times that the definition of RDEPEND= is unclear and that we
> | do infact need a new set
On Tue, 2005-25-10 at 20:16 +0100, Ciaran McCreesh wrote:
> On Tue, 25 Oct 2005 13:55:36 -0400 solar <[EMAIL PROTECTED]> wrote:
> | Please do not put words in my mouth. I've already asserted to you
> | several times that the definition of RDEPEND= is unclear and that we
> | do infact need a new set
On Tue, 25 Oct 2005 13:55:36 -0400 solar <[EMAIL PROTECTED]> wrote:
| Please do not put words in my mouth. I've already asserted to you
| several times that the definition of RDEPEND= is unclear and that we
| do infact need a new set of depend atoms. R=(runtime) not Buildtime
| for the NNth time. T
On Tue, 2005-10-25 at 17:39 +0100, Ciaran McCreesh wrote:
> On Tue, 25 Oct 2005 07:09:03 -0700 Donnie Berkholz
> <[EMAIL PROTECTED]> wrote:
> | I disagree. You shouldn't expect to be able to compile things against
> | it unless all DEPENDs are installed. The whole point of DEPEND is to
> | be able
On Tue, 25 Oct 2005 13:44:03 -0400 Alec Joseph Warner
<[EMAIL PROTECTED]> wrote:
| So define what you need to meet your goals, hell define your goals
| and agree on them ( or at least a subset ).
The goal is simple: have a working tree right now.
Any new dependency atom stuff would need to be at
Ciaran McCreesh wrote:
See, if libfoo-1.0's headers don't need (say) boost, but libfoo-1.1's
headers do, with what you're proposing you'd have to go through and
update the dependencies of every single package using libfoo.
That's true, and it's why I brought up the cascading DEPEND bit in the
Ciaran McCreesh wrote:
On Tue, 25 Oct 2005 11:16:54 -0600 Joshua Baergen
<[EMAIL PROTECTED]> wrote:
| Ciaran McCreesh wrote:
| >RDEPEND lists the things that are needed to use a package once it is
| >installed.
|
| Maybe RDEPEND is insufficient to properly describe a library
| package. I see a
Joshua Baergen wrote:
Fair enough. One possible solution is to use some agreed-upon
fooDEPEND within the current ebuilds and simply set for the time being:
DEPEND="${fooDEPEND} {DEPEND}"
Oh, and I didn't say this, but the point would be that if/when Portage
handles these situations changin
Ciaran McCreesh wrote:
Well yes, we already know we need a few dozen more new dependency
atoms. But we're dealing with "what we can use currently" here, not
some hypothetical future situation.
Fair enough. One possible solution is to use some agreed-upon fooDEPEND
within the current ebuilds
On Tue, 25 Oct 2005 11:16:54 -0600 Joshua Baergen
<[EMAIL PROTECTED]> wrote:
| Ciaran McCreesh wrote:
| >RDEPEND lists the things that are needed to use a package once it is
| >installed.
|
| Maybe RDEPEND is insufficient to properly describe a library
| package. I see a big difference between usi
Ciaran McCreesh wrote:
RDEPEND lists the things that are needed to use a package once it is
installed.
Maybe RDEPEND is insufficient to properly describe a library package. I
see a big difference between using and compiling against a library. I
realize you need to compile against it to us
Donnie Berkholz wrote: [Tue Oct 25 2005, 04:28:17AM CDT]
> I'm still failing to see how headers have anything to do with runtime
> issues -- it should be people's responsibility to ensure they have the
> necessary headers if they're compiling things that require them. And
> compiling means DEPEN
On Tue, 25 Oct 2005 09:28:17 + Donnie Berkholz
<[EMAIL PROTECTED]> wrote:
| I'm still failing to see how headers have anything to do with runtime
| issues -- it should be people's responsibility to ensure they have
| the necessary headers if they're compiling things that require them.
| And co
On Tue, 25 Oct 2005 07:09:03 -0700 Donnie Berkholz
<[EMAIL PROTECTED]> wrote:
| I disagree. You shouldn't expect to be able to compile things against
| it unless all DEPENDs are installed. The whole point of DEPEND is to
| be able to do things like this; remove all things not necessary for
| your p
Grant Goodyear wrote:
At the same time, I'm suppose that including header files by default is
not such a good thing for the embedded folks.
Exactly. And hacking around that with some USE flags for embedded just
says, to me, that we can't make a decision: we'll enforce this "usable
for compili
Donnie Berkholz wrote: [Mon Oct 24 2005, 11:37:03PM CDT]
> Now, the other side of the story. It's not true runtime dependence
> because it's not required for programs to run, only to compile. And the
> way I see it, things required for programs to compile are by definition
> DEPEND rather than RDEP
On Tuesday 25 October 2005 07:09, Donnie Berkholz wrote:
> Ciaran McCreesh wrote:
> | On Mon, 24 Oct 2005 21:37:03 -0700 Donnie Berkholz
> |
> | <[EMAIL PROTECTED]> wrote:
> | | Now, the other side of the story. It's not true runtime dependence
> | | because it's not required for programs to run, o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
| On Mon, 24 Oct 2005 21:37:03 -0700 Donnie Berkholz
| <[EMAIL PROTECTED]> wrote:
| | Now, the other side of the story. It's not true runtime dependence
| | because it's not required for programs to run, only to compile. And
| |
On Mon, 24 Oct 2005 21:37:03 -0700 Donnie Berkholz
<[EMAIL PROTECTED]> wrote:
| Now, the other side of the story. It's not true runtime dependence
| because it's not required for programs to run, only to compile. And
| the way I see it, things required for programs to compile are by
| definition DE
On Mon, 2005-10-24 at 21:37 -0700, Donnie Berkholz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Spider (D.m.D. Lj.) wrote:
> | If your package, libFoo, installs .h files that directly require header
> | files from libBar, then you have a Runtime dependency on libBar, not
> | only
On Mon, 24 Oct 2005 21:37:03 -0700
Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> The consequences of the two sides are like this, from what I can
> see:
>
> 1) Headers are run-time and build-time deps
> 2) Headers are build-time deps only
Imho, that case fall under the concept of "exported deps" i
On Mon, 2005-10-24 at 22:51 -0700, Donnie Berkholz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Spider (D.m.D. Lj.) wrote:
> | Why? Because they just install the hard RDEPEND, so if you have a system
> | installed from binaries, you get working linking, but nothing will
> | compile
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Spider (D.m.D. Lj.) wrote:
| Why? Because they just install the hard RDEPEND, so if you have a system
| installed from binaries, you get working linking, but nothing will
| compile for the system.
Right, until you actually install the build-time deps
> - - Binary packages don't require the header packages.
Theese are the main cause of pain in situations like this.
Why? Because they just install the hard RDEPEND, so if you have a system
installed from binaries, you get working linking, but nothing will
compile for the system.
Theese level
Donnie Berkholz wrote:
- - Packages requiring the headers have to DEPEND on them directly,
because DEPENDs don't cascade. (Although this brings to mind the concept
of some sort of cascadable DEPEND.)
I remember some sort of BDEPEND idea being proposed awhile back, but
that was for something d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Spider (D.m.D. Lj.) wrote:
| If your package, libFoo, installs .h files that directly require header
| files from libBar, then you have a Runtime dependency on libBar, not
| only a compile time dependency
|
|
| Why? Because libFoo should be usable
okay, this came up in a discussion today, and I figured it was time to
mention something about it here:
If your package, libFoo, installs .h files that directly require header
files from libBar, then you have a Runtime dependency on libBar, not
only a compile time dependency
Why? Because lib
36 matches
Mail list logo
