-1 to remove the requirement from Python until it is ready to be removed. See https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UNE6VTLKSS5EPR5RWS6AO4S4QFYJYTC4/

However, happy to produce Python-less tzdata-less containers. So basically +1 to the rest of the proposal.

I'm not sure whether it will be feasible to add Requires: tzdata in all the places where this is necessary (often implicitly), and fear that this will lead to broken applications when installed on top of minimal containers. As such, I'll vote -1, but I'm happy to be outvoted if others think this tradeoff is worth it.

I'm not sure the trade-off and pain is worth it.

-1

Would it be easier to just remove tzdata as part of the container build itself? There's other stuff stripped out in the container builds.

Doing this system wide feels like it could introduce a lot of pain.

I don't quite understand the opposition to this change. Removal of hardcoded dependencies is the bread-and-butter of minimization work. It is obviously clear that many (most?) container installations don't have any use for timezone data. The same would be true for initrds, possibly some embedded devices, etc. Generally anything that doesn't have a human user logging in doesn't need tzdata.

The proposal lists a few places where Requires: tzdata should be added, and we can handle those packages without any problem. It'll also be installed on "normal" installations because of the Recommends. The only place which the removal of the hard dependency could be a problem are minimal installations. But that is also the place where this change is most useful (and will be welcome, I'm sure).

Would it be easier to just remove tzdata as part of the container build itself? There's other stuff stripped out in the container builds.

That is of course possible, but it's a crutch. We do things like this, but this doesn't scale: we're adding another layer of file management on top of packaging. In the long run it's much better to make packaging more modular and instead make sure that the package is pulled in where appropriate.

In summary, except for the concrete issue with Python raised by Miro, other comments seem rather vague to me. In particular, people who build minimal containers are the most likely to welcome such a change. And people building those are generally power users who also test the containers before deploying them, and I expect that they would welcome this change. This is precisely the class of users that doesn't need handholding and mandatory dependencies.

We could just move forward with making glibc Recommends: tzdata along with other language runtimes, the actual implementation details can be changed?

It would be good to just start from the bottom up removing tzdata hard requirements where we can, but if we can't for some packages then those packages keep Requires: tzdata.

Thoughts?

That sounds like a sensible approach.

We could just move forward with making glibc Recommends: tzdata along with other language runtimes, the actual implementation details can be changed?

It would be good to just start from the bottom up removing tzdata hard requirements where we can, but if we can't for some packages then those packages keep Requires: tzdata.

Isn't this pretty much what the Change text describes?

We could just move forward with making glibc Recommends: tzdata along with other language runtimes, the actual implementation details can be changed?

It would be good to just start from the bottom up removing tzdata hard requirements where we can, but if we can't for some packages then those packages keep Requires: tzdata.

Isn't this pretty much what the Change text describes?

No quite. We listed Python on the "needs to be changed" list, and we could amend the proposal to move to to the "benificial to be changed" list.

Shall we amend the proposal to move Python from the "needs to change" list to the "beneficial to change" list?

@churchyard Would that resolve your objection?

Yes.

I am +1 to this change.

This change proposal has been edited to move Python from the "needs to change" list to the "beneficial to change" list.

+1

Please don't vote here unless you are a FESCo member, it makes it harder to couldn't the votes.

+1

+1

+1

We have both positive and negative votes, so I'm tagging this for today's meeting.

Sure. Not completely convinced, but why not, I guess?

+1

+1 to the updated change

This was discussed in today's FESCo meeting:
AGREED: APPROVED (+7, 0, -1)