robotpkg

/nix/store/kh542xlg6mgb14xwz22mvqpm8810aidp-bzip2-1.0.8-dev
├── include
│ └── bzlib.h
├── lib
│ └── pkgconfig
│ └── bzip2.pc
└── nix-support
└── propagated-build-inputs

So this particular bzip2-dev package splits headers and libraries?

While it makes sense to split bzip2 "tools" and "libraries", as
e.g. on debian with bzip2 libbz2-dev I don't really get the benefit of
this extra split. It seems even a bit unsafe, in the sense that you
could mix headers and libraries from different versions?

For bzip2 in robotpkg, it would also make sense to have split bzip2
and libbz2 packages, especially since the bootstrap only requires the
latter (I think).

I guess one option would be to split this package on robotpkg… But I
think that's way too much work for nothing.

It all depends on how many packages are involved. If all Nix packages
have separate headers and libs, yes, it's a bit overwhelming.

If it's only for packages that have both "tools" and "libs" then I
think it's cleaner and not too invasive.

But if you have other options in mind

Not really at the moment, and I am even a bit reluctant to handle different
prefixes for headers and libs for the same package, since the goal of
the 'system search' script was to expliticly avoid this situation :)
E.g. when you have /foo/pkg-1.0 and /bar/pkg-2.0, you don't want
headers from the first beeing used with the second ...

There's no way in Nix to configure a shared prefix for groups of
packages that must be consistent?

It's also easy to have different 'depend.mk' files in robotpkg even if
a package is not split.

Keeping the bzip2 example, there could be a 'depend-tool.mk' and
'depend-libs.mk'. The key used in 'DEPEND_USE' doesn't have to match a
package name, it's only a key to access 'DEPEND_ABI.key' (which
contents must match a robotpkg pkg name) and similar variables. So the
depend-*.mk files can use different keys and still refer to the same
robotpkg package when configured as PREFER.bzip2= robotpkg.

I see, thanks for your inputs !

I don't know how many packages are splitted in nix. I guess a lot.

I'll probably give depend-*.mk a try, at least on a couple system packages.

And yes, the point is to allow multiple versions of the same packages in /nix/store. The user is expected to activate only the prefixes of the version they want when they want. Obviously, the tooling makes this use easy enough, and it's almost impossible to activate multiple versions of the same package in the same environment by accident.
The goal is the opposite to be "a bit unsafe", as it easily allow fully reproducible builds, in a build system which is pure and written in functionnal way.

I'll probably cover this in a talk at 2RM :)

On Tuesday 12 Mar 2024, at 15:06, Guilhem Saurel wrote:

And yes, the point is to allow multiple versions of the same
packages in /nix/store.

The point I was raising was rather about mixed headers and libs from
the same package. E.g. foo-libs-1.0 vs. foo-headers-2.0. I don't see a
useful use case where mixing them would give any benefit?

having them in your /nix/store is not the same as mixing them. You can have foo-libs-1.0 and foo-headers-2.0 at the same time on you hard drive, without using them simultaneously in your current environment

On Tuesday 12 Mar 2024, at 20:16, Guilhem Saurel wrote:

having them in your /nix/store is not the same as mixing them. You
can have foo-libs-1.0 and foo-headers-2.0 at the same time on you
hard drive, without using them simultaneously in your current
environment

Sure. But if you can set independant prefixes in robotpkg (or any
build system) for the two, then you can easily mix them by mistake.

If you declare them manually, yes, clearly. But this would be super tedious to do this manually by handling those horrible hashes anyway.
This is supposed to be used from a source generated by a purely functional declarative system, which prevent such kind of mistake.