Handling of dependency versions in ebuilds. #2

Closed
opened 4 years ago by Chris · 3 comments
Chris commented 4 years ago
Collaborator

After there is consens that this overlay is maintained at best efforts and after looking again at the tdelibs ebuilds, I noticed that there are depends on mutiple libraries which minimum versions aren't in the whole Portage tree anymore since some longer time. That means normaly there isn't any need to keep them and for reasons of a better maintenance there is the question if it is still needed to depend on these specific versions for tdelibs as minimum. The same is true for TQt I just noticed.

As known TDE isn't depending on the very latest libraries and it's more the other way, that too new ones will more likely break something. There could be the rare case, when users still have some of these installed these days, but I don't know if that is realistic.

After there is consens that this overlay is maintained at best efforts and after looking again at the tdelibs ebuilds, I noticed that there are depends on mutiple libraries which minimum versions aren't in the whole Portage tree anymore since some longer time. That means normaly there isn't any need to keep them and for reasons of a better maintenance there is the question if it is still needed to depend on these specific versions for tdelibs as minimum. The same is true for TQt I just noticed. As known TDE isn't depending on the very latest libraries and it's more the other way, that too new ones will more likely break something. There could be the rare case, when users still have some of these installed these days, but I don't know if that is realistic.
Collaborator

It's probably safe to drop any minimum versions that aren't internal to TDE (it makes sense to have =tdelibs-${PV} and the like in most places) and that have aged out of the main Portage tree. For extra safety, it might be good to check to see if they were dropped more than a year ago. If a lot of people who have kept old libs for some reason suddenly appear out of the woodwork, we can worry about fixing things then.

It's probably safe to drop any minimum versions that aren't internal to TDE (it makes sense to have =tdelibs-${PV} and the like in most places) and that have aged out of the main Portage tree. For extra safety, it might be good to check to see if they were dropped more than a year ago. If a lot of people who have kept old libs for some reason suddenly appear out of the woodwork, we can worry about fixing things then.
Chris commented 4 years ago
Poster
Collaborator

Good point and idea about that year. Seems reasonable to me. So I will remove that at least for the live ebuilds and if you want, also for the stabel ebuilds, with your permission. 👍

Good point and idea about that year. Seems reasonable to me. So I will remove that at least for the live ebuilds and if you want, also for the stabel ebuilds, with your permission. :+1:
Chris commented 4 years ago
Poster
Collaborator

After finding consens in the one year or more rule, we can close this and will keep that in mind for new ebuilds or anything other too.

After finding consens in the one year or more rule, we can close this and will keep that in mind for new ebuilds or anything other too.
Chris closed this issue 4 years ago
Chris added this to the R14.0.8 release milestone 4 years ago
Chris changed title from Handling of dependency versions of tdelibs ebuilds. to Handling of dependency versions ebuilds. 4 years ago
Chris changed title from Handling of dependency versions ebuilds. to Handling of dependency versions in ebuilds. 4 years ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: TDE/tde-packaging-gentoo#2
Loading…
There is no content yet.