systemd

[scopatz]

Checklist

• License file is packaged (see here for an example)
• Source is from official source
• Package does not vend other packages
• Build number is 0
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details)
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there

In what is surely one of the most ridiculous recipes, here is systemd (which compiles and builds for me locally). This is needed to get a modern version of libudev on conda-forge, which is needed to get our bluetooth stack up (bluez, pybluez, etc).

[mingwandroid]

I worry about this. It's a dangerous path IMHO. Better to use cdt packages from centos7 Your system provides it, and it is PID1.

I'm far from expert in systemd but if there's one library in our ecosystem that is clearly in the realm of the system it is this one!.. Or any other init system.

I don't believe there aren't other better ways. Also I believe the libudev you build on to of this will not have access to system resources! Happy to be wrong though..

[scopatz]

Better to use cdt packages from centos7 Your system provides it, and it is PID1.

We can't install centos7 CDT packages on conda forge, though, because it is all centos6 based. I'd be happy to be wrong here

[isuruf]

It's not possible at the moment, but a plan is at conda-forge/conda-forge.github.io#900. Other than step3, all the others are easy to do.

[scopatz]

So this is a work around for not having CDTs for the current state of the world

[isuruf]

Let me clarify, you can have a CDT for cos7 with conda-forge right now. Adding a cos7 docker image will make it usable at build stage and testing.

[scopatz]

@isuruf @mingwandroid - Is that what should be done? I have this working now, but if you think that is a better option, I can pursue that instead. That package wouldn't be installable on our centos6 images, though, right? So all downstream packages would also have to be built on the centos7 image. Is that correct?

[scopatz]

Also, I have put in this PR to create the Centos7 image: conda-forge/docker-images#119

[mingwandroid]

I have this working now

That's good, honestly and thanks for doing the work (at the very least it's an option or useful reference), but to what level? What tools did you build? If users run them on an old system will the corrupt their systemd config files by emiting newer config stuff that old systemd doesn't grok?

[mingwandroid]

So all downstream packages would also have to be built on the centos7 image. Is that correct?

No, that is not necessary.

[scopatz]

If users run them on an old system will the corrupt their systemd config files by emiting newer config stuff that old systemd doesn't grok?

Yeah, I am not so concerned about the older systems because I don't mind users having to have newer systems to use these packages. So in some sense this whole effort is about how we express that certain packages require newer kernel versions.

No, that is not necessary.

great!

[isuruf]

So in some sense this whole effort is about how we express that certain packages require newer kernel versions.

This should be done using virtual packages. See point 1 in conda-forge/conda-forge.github.io#900

[scopatz]

I am not sure there is a need for a virtual package here once there is a CDT of systemd available.

[isuruf]

Upto this point, all our packages have been cos6 compatible. How do you tell end-users that you need a cos7 system or newer for a specific package? That's where virtual packages come in.

[scopatz]

How would I make a virtual package that specifies this. The link in point one from conda-forge/conda-forge.github.io#900 wasn't descriptive enough for me

[isuruf]

It should be done in conda like conda/conda#9349 and any package needing a newer GLIBC, should add a run_constrained for that virtual package.

[scopatz]

Wait, so the virtual package has to be added to conda itself?

[isuruf]

Yes, and then any package needing cos7 has to add it as a run_constrained to make them installable in older conda versions.

[scopatz]

Well, so should the virtual package be for cos7 or on systemd?

[isuruf]

It should be for glibc. See conda-forge/conda-forge.github.io#900 (comment) and https://github.com/conda/conda/blob/e200258259dd47ef131937b17c32a363b64dbec9/conda/base/context.py#L755

[scopatz]

PR for virtual package at conda/conda#9358

[stale]

Hi friend!

We really, really, really appreciate that you have taken the time to make a PR on conda-forge/staged-recipes! conda-forge only exists because people like you donate their time to build and maintain conda recipes for use by the community.

In an effort to maintain this repository and increase the signal-to-noise for open PRs, the maintainers of staged-recipes close excessively old PRs after six months. This PR will remain open for another month, and then will be closed.

If you'd like to keep it open, please comment/push and we will be happy to oblige! Note that very old PRs will likely need to be rebased on master so that they can be rebuilt with the most recent CI scripts. If you have any trouble, or we missed reviewing this PR in the first place (sorry!), feel free to ping the team using a special command in a comment on the PR to get the attention of the staged-recipes team.

Cheers and thank you for contributing to this community effort!

[stale]

Hi again! About a month ago, we commented on this PR saying it would be closed in another month if it was still inactive. It has been a month and so now it is being closed. Thank you so much for making it in the first place and contributing to the community project that is conda-forge. If you'd like to reopen this PR, please feel free to do so at any time!

Cheers and have a great day!