[gentoo-dev] Reminder on dependencies.

[gentoo-dev] Reminder on dependencies.

[Spider (D.m.D. Lj.)]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

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 libFoo should be usable at runtime, even for compiling
things not managed by our tree. And if   BazPack has a configure check,
requires explicitly  libFoo,  tests for the presence of said header, and
all checks out.. Then BazPack should be able to work,  and libFoo's
header certainly shouldn't be broken for use in compile.

Runtime isn't only executables. 


//Spider

-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Donnie Berkholz]

-----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 at runtime, even for compiling
| things not managed by our tree. And if   BazPack has a configure check,
| requires explicitly  libFoo,  tests for the presence of said header, and
| all checks out.. Then BazPack should be able to work,  and libFoo's
| header certainly shouldn't be broken for use in compile.

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 RDEPEND.

The consequences of the two sides are like this, from what I can see:

1) Headers are run-time and build-time deps

- - Headers have to be installed even when you're using purely binary
packages, because they are supposedly needed at "runtime" for your
packages to work.

- - Also, header packages can't be uninstalled after the build via
depclean because they're specified as run-time dependencies.

2) Headers are build-time deps only

- - Binary packages don't require the header packages.

- - Header packages can be unmerged after builds.

- - 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'd like to hear what some other people think about this.

Thanks,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDXbZvXVaO67S1rtsRAr54AKDOMyoDoqBtogZu62eVV65Erv4nYACgukFK
MP1+UujlQePnkCckhseZYsw=
=HU3R
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Reminder on dependencies.

[Joshua Baergen]

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 different I believe.  I wouldn't mind the ability 
to say that DEPENDing on x at build-time requires y during the build 
process, especially if more packages follow X's header structure.

--
Joshua Baergen
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Reminder on dependencies.

[Ned Ludd]

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 a compile time dependency
> |
> |
> | Why?   Because libFoo should be usable at runtime, even for compiling
> | things not managed by our tree. And if   BazPack has a configure check,
> | requires explicitly  libFoo,  tests for the presence of said header, and
> | all checks out.. Then BazPack should be able to work,  and libFoo's
> | header certainly shouldn't be broken for use in compile.
> 

> 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 RDEPEND.

exactly.

> The consequences of the two sides are like this, from what I can see:
> 
> 1) Headers are run-time and build-time deps
> 
> - - Headers have to be installed even when you're using purely binary
> packages, because they are supposedly needed at "runtime" for your
> packages to work.
> 
> - - Also, header packages can't be uninstalled after the build via
> depclean because they're specified as run-time dependencies.
> 


> 2) Headers are build-time deps only
> 
> - - Binary packages don't require the header packages.
> 
> - - Header packages can be unmerged after builds.
> 
> - - 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'd like to hear what some other people think about this.

Well put Donnie. 

--

emerge -B virtual/libc busybox
ROOT=/mnt/foo emerge -K virtual/libc busybox

# if this were to pull in linux-headers on the second step into the 
$ROOT then all embedded support would be shot.

+1 vote to ignore Spiders mail and revert such changes that put headers 
in rdeps as it has undesirable side effects to existing supported 
projects.


-- 
Ned Ludd <solar@gentoo.org>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Reminder on dependencies.

[Spider (D.m.D. Lj.)]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]


> - - 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 of inheritance bugs are a ripe minefield for the whole
distribution, and one that will severely damage the distribution as a
whole.    one way of solving it is to go through each and every
top-level application and violently scan all its included files, and all
files included from those headers in turn, in order to get the
dependencies right.

The other is to fix the level closest to the breakage by making sure
that headers are treated like libraries.


Hope I'm making this clear enough, its fairly early.

//Spider


-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Donnie Berkholz]

-----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. Not unexpected or
surprising after thinking about it.

| Theese level of inheritance bugs are a ripe minefield for the whole
| distribution, and one that will severely damage the distribution as a
| whole.    one way of solving it is to go through each and every
| top-level application and violently scan all its included files, and all
| files included from those headers in turn, in order to get the
| dependencies right.
|
| The other is to fix the level closest to the breakage by making sure
| that headers are treated like libraries.
|
|
| Hope I'm making this clear enough, its fairly early.

So there's a harder but more technically correct solution (specifying
includes as DEPENDs where necessary), and an easier but not as correct
solution (considering build-time dependencies as run-time dependencies).

At least that's how things look from my perspective.

Thanks,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDXcf6XVaO67S1rtsRAvQ7AKCCFU45+c6Davjb6WW8P1Xh2ymmowCggDxt
1xSuZbKtdsRy+kk/22rQysE=
=QrS4
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Reminder on dependencies.

[Spider (D.m.D. Lj.)]

[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]

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 for the system.
> 
> Right, until you actually install the build-time deps. Not unexpected or
> surprising after thinking about it.
> 
> | Theese level of inheritance bugs are a ripe minefield for the whole
> | distribution, and one that will severely damage the distribution as a
> | whole.    one way of solving it is to go through each and every
> | top-level application and violently scan all its included files, and all
> | files included from those headers in turn, in order to get the
> | dependencies right.
> |
> | The other is to fix the level closest to the breakage by making sure
> | that headers are treated like libraries.
> |
> |
> | Hope I'm making this clear enough, its fairly early.
> 
> So there's a harder but more technically correct solution (specifying
> includes as DEPENDs where necessary), and an easier but not as correct
> solution (considering build-time dependencies as run-time dependencies).
> 
> At least that's how things look from my perspective.

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 sources, or sources from Gentoo.

We can hack around the later by being fanatical with our own DEPEND
tracking, for the other two, our tree will remain completely broken.

This is a case where we, a source based distro, is actually a crappier
development platform than any of the current binary distributions.


//Spider

-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Thomas de Grenier de Latour]

On Mon, 24 Oct 2005 21:37:03 -0700
Donnie Berkholz <spyderous@gentoo.org> 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 had
proposed some time ago, here:
http://thread.gmane.org/gmane.linux.gentoo.portage.devel/750

Quickly summarized, the idea (for RDEPEND) was, for instance, the
following:
- pkgA installs libA.so, and depending on USE flag "flagB", it's
libA.la file may contain "-lB".
- thus, a pkgC linked to libA may also be linked to libB, but that
depends on USE flags of pkgA, which can't be taken into account in
pkgC's RDEPEND. In such cases, one simply can't write correct
RDEPEND for pkgC.
- the proposed solution was that pkgA.ebuild declares a
EXPORTED_RDEPEND="flagB? ( pkgB )" variable. Evaluation of this
variable ("pkgB" or empty, depending on whether flagB was set at
pkgA compile time) would be stored in pkgA vardb metadatas, and
packages RDEPENDing on pkgA would also automatically include this
result in there RDEPENDs. Thus, pkgC would get correct RDEPENDs,
depending how pkgA was compiled.

Sure, the idea also applies for DEPEND (didn't talk about it in my
initial RFC, but that's required anyway for the above example with
libs explicitly linked through .la files). In the case of "headers
including other headers", it would be as follow:
 - pkgA installs headerA.h, which has an "#include <headerB.h>"
 - since pkgA's binaries/libs don't need pkgB at runtime, it doesn't
have an RDEPEND on this pkgB. But it should EXPORT_DEPEND="pkgB".
 - pkgC, which has a DEPEND="pkgA", would then automatically import
a DEPEND on pkgB.

Now, that's just a vague idea of portage improvement. Not sure how
good/bad it is, but anyway it's not something that would be
available anytime soon. And until something like that is possible,
i tend to agree Spider that cluttering RDEPENDs is the less worst
one can do to make things work.

--
TGL.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Reminder on dependencies.

[Donnie Berkholz]

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 compiling" thing most of the time, but not for them. So it's a rule 
of convenience.

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 DEPEND.

Maybe for some people compiling is included in runtime, but I'm not one 
of them.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Reminder on dependencies.

[Donnie Berkholz]

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 
original e-mail.

If we decide that a new dependency atom is what we need, I'd rather have 
the temporary solution be one that people have some motivation to 
change. Otherwise it won't be temporary, it'll just sit there and rot 
forever.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Reminder on dependencies.

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

On Mon, 24 Oct 2005 21:37:03 -0700 Donnie Berkholz
<spyderous@gentoo.org> 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 RDEPEND.

Not at all. If you've installed libfoo, one of the things you must be
able to do is compile things that use libfoo. This sometimes means that
libfoo would need a non-build-time dependency upon any libraries used
by libfoo's header files.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
| On Mon, 24 Oct 2005 21:37:03 -0700 Donnie Berkholz
| <spyderous@gentoo.org> 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 RDEPEND.
|
| Not at all. If you've installed libfoo, one of the things you must be
| able to do is compile things that use libfoo. This sometimes means that
| libfoo would need a non-build-time dependency upon any libraries used
| by libfoo's header files.

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
programs to run, not to compile.

Thanks,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDXjx/XVaO67S1rtsRAhSCAKCx+hz350OYMt0DHbH2IioPzMxjiwCcCSMF
yHlfBgfSVWIKJ5HVi9pOMz4=
=WHBM
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Reminder on dependencies.

[John Myers]

[-- Attachment #1: Type: text/plain, Size: 2076 bytes --]

On Tuesday 25 October 2005 07:09, Donnie Berkholz wrote:
> Ciaran McCreesh wrote:
> | On Mon, 24 Oct 2005 21:37:03 -0700 Donnie Berkholz
> |
> | <spyderous@gentoo.org> 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 RDEPEND.
> |
> | Not at all. If you've installed libfoo, one of the things you must be
> | able to do is compile things that use libfoo. This sometimes means that
> | libfoo would need a non-build-time dependency upon any libraries used
> | by libfoo's header files.
>
> 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
> programs to run, not to compile.

Perhaps, then, an additional dependency type would be useful? One that says "I 
may or may not need this for me to compile, Other programs definately need 
this to compile against me, and I don't necessarily need this to run"

Let's call this CDEPEND, for the sake of example:
package foo DEPENDs on bar, but does not CDEPEND or RDEPEND on it. bar 
CDEPENDs on baz, but does not DEPEND or RDEPEND on it.

Scenario 1:
1) emerge bar
- bar installed
2) emerge foo
- baz installed
- foo installed

Scenario 2:
1) emerge foo
- baz installed
- bar installed
- foo installed
2) "remove all compilation-only packages"
- bar uninstalled
- baz uninstalled
3) emerge bar
- bar installed
4) emerge -u foo
- baz installed
- foo installed

The pattern is that CDEPENDs of package fooquux are optional unless another 
package in the current dep list DEPENDs on fooquux. Only DEPEND would 
activate them, not RDEPEND or CDEPEND, so if fooquux needs a package in 
CDEPEND to compile, it must also specify it in DEPEND, and if it needs it at 
runtime, it must also specify it in RDEPEND.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 2467 bytes --]

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 RDEPEND.

I think I'm w/ spider on this one.  At the risk of initiating a semantic
scuffle, my view is that the DEPEND and RDEPEND variables exist solely
to tell portage what packages are needed for portage to produce a
fully-functional package.  A library w/ missing header dependencies is
clearly not fully-functional, so portage needs to include that
dependency even if it is a binary package that is being installed.  The 
way to do that is to include the dependency in RDEPEND, even if the name
seems to be not quite appropriate.

> The consequences of the two sides are like this, from what I can see:
> 
> 1) Headers are run-time and build-time deps
> 
> - - Headers have to be installed even when you're using purely binary
> packages, because they are supposedly needed at "runtime" for your
> packages to work.
> 
> - - Also, header packages can't be uninstalled after the build via
> depclean because they're specified as run-time dependencies.
> 
> 2) Headers are build-time deps only
> 
> - - Binary packages don't require the header packages.
> 
> - - Header packages can be unmerged after builds.
> 
> - - 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'd like to hear what some other people think about this.

I've always been a big fan of the fact that by default we install
fully-capable packages that include headers, because it makes Gentoo
much more appealing to developers.  My group is working on some
cryo-microscopy software that incorporates quite a number of scientific
and graphical libraries, and setting up Ubuntu or Debian for one of our
project developers was a pain as I struggled to ensure that I had all of
the necessary development packages installed.

At the same time, I'm suppose that including header files by default is
not such a good thing for the embedded folks.

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

On Tue, 25 Oct 2005 07:09:03 -0700 Donnie Berkholz
<spyderous@gentoo.org> 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 programs to run, not to compile.

I'm glad to see you're volunteering to join in with Ned in going
through every single ebuild in the tree and fixing them up to list nth
level dependencies. It's going to be really fun watching you update
several hundred packages every time a library's compile dependencies
change between versions.

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.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 788 bytes --]

On Tue, 25 Oct 2005 09:28:17 +0000 Donnie Berkholz
<spyderous@gentoo.org> 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 compiling means DEPEND.

Yick. No no no.

DEPEND lists the things that are needed to install a package from
source (or an upstream-provided binary, or whatever).

RDEPEND lists the things that are needed to use a package once it is
installed.

Part of 'using' a library is compiling things against it.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]

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 DEPEND.

It's possible that I'm being particularly dense today, but at least at
the moment it seems fairly simple to me.  DEPEND means that portage
requires the dep for the current package to build successfully.
RDEPEND, on the other hand, lists dependencies that users of a package
will need down the road, after it's installed on the system.  So, for
example, libfoo might not require that boost be installed for it to
build, but libfoo might export a header file that imports
boost/tuple.hpp.  If boost isn't in libfoo's RDEPEND, then when user
Fred installs libfoo from a binary package and tries to use libfoo's
header files in development, a rude shock is likely.

> 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
binary packages.

My apologies if I'm missing the point here.

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Joshua Baergen]

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 use it, but that's certainly 
not a run-time dependency.

--
Joshua Baergen
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Reminder on dependencies.

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

On Tue, 25 Oct 2005 11:16:54 -0600 Joshua Baergen
<joshuabaergen@gentoo.org> 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 using and compiling against
| a library.  I realize you need to compile against it to use it, but
| that's certainly not a run-time dependency.

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.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Joshua Baergen]

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 and simply set for the time being:

DEPEND="${fooDEPEND} {DEPEND}"

at the end of the DEPEND list.  This way we can solve the current 
compile problem, but for those who care a simple sed call will turn 
those headers into RDEPENDS.  This could work the other way around as 
well of course.

--
Joshua Baergen
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Reminder on dependencies.

[Joshua Baergen]

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 changing the ebuilds would be simple.

--
Joshua Baergen
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Reminder on dependencies.

[Alec Joseph Warner]

Ciaran McCreesh wrote:
> On Tue, 25 Oct 2005 11:16:54 -0600 Joshua Baergen
> <joshuabaergen@gentoo.org> 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 using and compiling against
> | a library.  I realize you need to compile against it to use it, but
> | that's certainly not a run-time dependency.
> 
> 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.
> 

So define what you need to meet your goals,  hell define your goals and 
agree on them ( or at least a subset ).  Right now you are just arguing 
back and forth over this small issue.  What other issues does the 
current system impose?  What do you suggest to fix them?  What manner of 
"few dozen more new dependency atoms" are needed and what do they do?
How can you reconcile the goals of compiling against library headers vs 
embedded's space need?

With the ideal case decided you can A.  Move gentoo to get closer to 
that case; and B.  Know the deficiencies in the current implementation.

Right now it just looks like a bunch of people bickering over a policy 
issue.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Reminder on dependencies.

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]

On Tue, 25 Oct 2005 13:44:03 -0400 Alec Joseph Warner
<warnera6@egr.msu.edu> 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 least a GLEP. That is
a separate discussion which is not relevant here.

| Right now it just looks like a bunch of people bickering over a
| policy issue.

No, we're discussing how to avoid having a broken tree. It is entirely
possible to have technical discussions which are not 'bickering' or
'flame wars'. A thread with more than a half dozen posts often just
means something slightly tricky is under discussion.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[solar]

On Tue, 2005-10-25 at 17:39 +0100, Ciaran McCreesh wrote:
> On Tue, 25 Oct 2005 07:09:03 -0700 Donnie Berkholz
> <spyderous@gentoo.org> 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 programs to run, not to compile.
> 
> I'm glad to see you're volunteering to join in with Ned in going
> through every single ebuild in the tree and fixing them up to list nth
> level dependencies. It's going to be really fun watching you update
> several hundred packages every time a library's compile dependencies
> change between versions.


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. Till then please focus your efforts on something useful that
does not break other peoples systems or projects.

> 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.



-- 
solar <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Reminder on dependencies.

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

On Tue, 25 Oct 2005 13:55:36 -0400 solar <solar@gentoo.org> 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. Till then please focus your efforts on something
| useful that does not break other peoples systems or projects.

Given the choice of possibly causing minor inconvenience to the embedded
people or outright breaking the tree for every single user, the sane
option is to keep the tree working. If embedded has a requirement for
better DEPEND specifications, why don't they start working on a GLEP?

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Olivier Crete]

On Tue, 2005-25-10 at 20:16 +0100, Ciaran McCreesh wrote:
> On Tue, 25 Oct 2005 13:55:36 -0400 solar <solar@gentoo.org> 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. Till then please focus your efforts on something
> | useful that does not break other peoples systems or projects.
> 
> Given the choice of possibly causing minor inconvenience to the embedded
> people or outright breaking the tree for every single user, the sane
> option is to keep the tree working. If embedded has a requirement for
> better DEPEND specifications, why don't they start working on a GLEP?

Maybe I dont get the problem of the embedded people, but why don't they
just rm -rf /usr/include (or INSTALL_MASK it)

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Reminder on dependencies.

[solar]

On Tue, 2005-10-25 at 20:16 +0100, Ciaran McCreesh wrote:
> On Tue, 25 Oct 2005 13:55:36 -0400 solar <solar@gentoo.org> 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. Till then please focus your efforts on something
> | useful that does not break other peoples systems or projects.
> 
> Given the choice of possibly causing minor inconvenience to the embedded
> people or outright breaking the tree for every single user, the sane
> option is to keep the tree working. If embedded has a requirement for
> better DEPEND specifications, why don't they start working on a GLEP?


Embedded GLEP eh?
You two are the ones trying to distort the meaning of RDEPEND= 
simply because the depclean is broken for the cases you make.

Where is your GLEP for this? Where is a real like example?
I'm sure you can dig back in the tree and show us something you had to 
fix in the tree if this is such a problem as you were asserting 
last night. While your at it please go ahead and show us the code that
resolves the case for everybody so this silly thread can end.

I've already busted by ass and fixed the vital broken packages and
eclasses which INCORRECTLY included linux-headers etc in RDEPEND= we
already worked with releng and other groups to ensure that things
function properly, so heh no GLEP is needed from embedded as things
are/were functioning correctly.

-- 
solar <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Reminder on dependencies.

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

On Tue, 25 Oct 2005 16:05:00 -0400 solar <solar@gentoo.org> 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 keeping the tree small, naming the
variable STUFFTHATISNEEDEDAFTERTHECOMPILEISDONEDEPEND is clearly
impractical.

| Where is your GLEP for this? Where is a real like example?
| I'm sure you can dig back in the tree and show us something you had
| to fix in the tree if this is such a problem as you were asserting 
| last night. While your at it please go ahead and show us the code that
| resolves the case for everybody so this silly thread can end.

I'd hope that there aren't any cases of brokenness in the tree right
now. However, if you'd like to manufacture some, an easy way would be
to find any library (call it lib1) that installs a .h file that uses
a .h file from another library (call it lib2), and then remove the
dependency, unmerge the original library and then try to install a
package which depends upon lib1.

You're assuming that if lib1 needs something from lib2 then there will
be an ELF dependency. This is incorrect in situations where templates
are used.

| I've already busted by ass and fixed the vital broken packages and
| eclasses which INCORRECTLY included linux-headers etc in RDEPEND=

Which is entirely different from things which CORRECTLY include
linux-headers or any other library in DEPEND.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]

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 sources, or sources from Gentoo.
>
> We can hack around the later by being fanatical with our own DEPEND
> tracking, for the other two, our tree will remain completely broken.
>
> This is a case where we, a source based distro, is actually a crappier
> development platform than any of the current binary distributions.

I agree with Spider here. DEPEND in package x to me means what is needed 
to make x build. RDEPEND in package x means what is needed to use package 
x. There are various uses of x. One is running said package, another one 
is building some other package (say y) against it.

This last meaning (building y against x) might have been put in a separate 
dependency variable. This however is not so usefull as we have the 
current format. But putting that meaning in DEPEND would mean that 
portage would certainly need to merge all build time dependencies of a 
package x to merge y. As such packages like virtual/jdk, autoconf, 
automake might be unneededly pulled in.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.ru.nl
Homepage: http://www.devrieze.net

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

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 RDEPEND.
>
> exactly.
It is required to use all parts of the ebuild. header files are also 
runtime parts.

>
> emerge -B virtual/libc busybox
> ROOT=/mnt/foo emerge -K virtual/libc busybox
>
If you wan to do this, you'd probably have to change the libc ebuild to 
have an embedded (or binary-only) useflag that would not install the libc 
headers (and thus not need the kernel headers).

> # if this were to pull in linux-headers on the second step into the
> $ROOT then all embedded support would be shot.

No, embedded might be rethought to do things properly.

>
> +1 vote to ignore Spiders mail and revert such changes that put headers
> in rdeps as it has undesirable side effects to existing supported
> projects.
>

+1 vote to take spiders mail seriously and solve the problem properly. 
First by putting the headers in RDEPEND and adding a new variable in a 
new EAPI version to solve it for new ebuilds.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.ru.nl
Homepage: http://www.devrieze.net

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

On Tuesday 25 October 2005 22:38, Ciaran McCreesh wrote:
> On Tue, 25 Oct 2005 16:05:00 -0400 solar <solar@gentoo.org> 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 keeping the tree small, naming the
> variable STUFFTHATISNEEDEDAFTERTHECOMPILEISDONEDEPEND is clearly
> impractical.

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 after buildtime-only 
dependencies have been removed.

In the case of embedded it is clear that what in binary distributions is 
part of the development package (.la files, static libraries, header 
files) is not desired at all. To break dependencies to only strip away 
some of the headers seems to me a half solution that breaks a lot and 
doesn't solve the problem either.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

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
> binary packages.

I think we should also remember that depclean removes/should remove 
build-time dependencies. So also when only working source-based packages 
this could be an issue. Runtime to me only means (post-buildtime). The 
header deps are only not needed when the headers are not installed at 
all.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Luca Barbato]

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 after buildtime-only 
> dependencies have been removed.

I agree too

> 
> In the case of embedded it is clear that what in binary distributions is 
> part of the development package (.la files, static libraries, header 
> files) is not desired at all. To break dependencies to only strip away 
> some of the headers seems to me a half solution that breaks a lot and 
> doesn't solve the problem either.
> 
> Paul
> 

Btw embedded has already different way to archive the same result (ok, 
removing headers and static libs after isn't really the cleanest 
solution but works fine)

lu

-- 

Luca Barbato

Gentoo/linux Developer		Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Reminder on dependencies.

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

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
> > installed one should be able to assume that they keep on working.
> > Even after buildtime-only dependencies have been removed.
>
> I agree too
>
> > In the case of embedded it is clear that what in binary distributions
> > is part of the development package (.la files, static libraries,
> > header files) is not desired at all. To break dependencies to only
> > strip away some of the headers seems to me a half solution that
> > breaks a lot and doesn't solve the problem either.
> >
> > Paul
>
> Btw embedded has already different way to archive the same result (ok,
> removing headers and static libs after isn't really the cleanest
> solution but works fine)

The hardest part is probably to build all these packages as the finals 
shouldn't have headers while the intermediates (used to build other 
finals against) should.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

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 files) is not desired at all. To break dependencies to only
> > > strip away some of the headers seems to me a half solution that
> > > breaks a lot and doesn't solve the problem either.
> >
> > Btw embedded has already different way to archive the same result (ok,
> > removing headers and static libs after isn't really the cleanest
> > solution but works fine)
> 
> The hardest part is probably to build all these packages as the finals 
> shouldn't have headers while the intermediates (used to build other 
> finals against) should.

Again, why not leave everything in the packages and use INSTALL_MASK on
embedded systems ?

-- 
Olivier Crête
tester@gentoo.org
x86 Security Liaison

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Reminder on dependencies.

[Ned Ludd]

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 the development package (.la files, static libraries,
> > > > header files) is not desired at all. To break dependencies to only
> > > > strip away some of the headers seems to me a half solution that
> > > > breaks a lot and doesn't solve the problem either.
> > >
> > > Btw embedded has already different way to archive the same result (ok,
> > > removing headers and static libs after isn't really the cleanest
> > > solution but works fine)
> > 
> > The hardest part is probably to build all these packages as the finals 
> > shouldn't have headers while the intermediates (used to build other 
> > finals against) should.
> 
> Again, why not leave everything in the packages and use INSTALL_MASK on
> embedded systems ?


This thread can end. ciaranm provided an example yesterday and his case 
is pretty much for c++ templates and the cases I'm making are for 
things like (example thats no longer valid) wireless-tools pulling in
linux headers and or source into a $ROOT via $RDEPEND due some eclass.

INSTALL_MASK was created for embedded systems by iggy to partially deal
with this sorta problem. It helps but it's not the end all solution.


-- 
Ned Ludd <solar@gentoo.org>

-- 
gentoo-dev@gentoo.org mailing list