| Summary: | Split KDE ebuilds should not force mixing of KDE versions | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Martin Väth <martin> |
| Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
| Status: | VERIFIED WONTFIX | ||
| Severity: | enhancement | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
This isn't going to happen - the whole point of the split ebuilds is that upgrading unchanged packages is no longer needed. Adding artificially inflated version bumps is only going to make things harder to maintain. If you have a real problem with the size of the tarballs, please stick with the monolithic ebuilds. (In reply to comment #1) > the whole point of the split ebuilds is that upgrading unchanged packages is > no longer needed. Which is very useful for e.g. kmail-3.5.5 -> kmail-3.5.5-r1 so that no complete kdepim has to be recompiled. Here it really makes sense, and the maintainer knows anyway what has changed. However, for e.g. kde-3.5.5 -> kde-3.5.6 it makes not much sense to safe recompilation of 4-7 tiny packages and to buy this gain with 4-7 huge tarballs and having to check all packages for changes. > Adding artificially inflated version bumps is only going to make things > harder to maintain. I really don't understand why having to check carefully every package for changes after a kde upgrade should be simpler than just bumping everything. But of course, the decision is up to the maintainer who does the work... > please stick with the monolithic ebuilds. Not an option, since this forces to install everything of KDE which cannot be done on computers where the additional tarballs are an issue (i.e. where the diskspace is low). So I will keep bumping in my local overlay - I just thought that other people have this problem, too. (In reply to comment #2) > (In reply to comment #1) > > the whole point of the split ebuilds is that upgrading unchanged packages is > > no longer needed. > Which is very useful for e.g. kmail-3.5.5 -> kmail-3.5.5-r1 so that no complete > kdepim has to be recompiled. Here it really makes sense, and the maintainer > knows anyway what has changed. However, for e.g. kde-3.5.5 -> kde-3.5.6 it > makes not much sense to safe recompilation of 4-7 tiny packages and to buy this > gain with 4-7 huge tarballs and having to check all packages for changes. It does. You don't need to recompile an application that has not changed. See it however you want, this is is the objective way to see it: if it's the same, there is no need to recompile it. > > Adding artificially inflated version bumps is only going to make things > > harder to maintain. > I really don't understand why having to check carefully every package for > changes after a kde upgrade should be simpler than just bumping everything. Because it means unnecessary overhead. > But of course, the decision is up to the maintainer who does the work... > > please stick with the monolithic ebuilds. The decission is taken after checking the pros and cons. Here there are no cons against what we do. Use monolithic ebuilds if you don't like it. > Not an option, since this forces to install everything of KDE which cannot be > done on computers where the additional tarballs are an issue (i.e. where the > diskspace is low). The use split ebuilds and get over it. > So I will keep bumping in my local overlay - I just thought that other people > have this problem, too. Up to you, the proposed and working solution does the work as it should be done. |
Everytime when a new kde version comes out, most split ebuild are upgraded simultaneously to that version - which is rather fine. However, some very few ebuilds are not updated; I guess because you verified that the corresponding code in kde has not changed and can be used from the older version. In my case (but I have not installed everything from kde, so no claim of completeness) the corresponding packages from the current kde 3.5.5 are just these few: kcheckpass kcminit kreadconfig kstart libkmime libksieve i.e. these packages are not available for kde-3.5.5 (although they are needed there) but only from (various) older kde-versions. From the viewpoint of a user with limited disk space and bandwidth these few "orphaned" versions are very unfortunate, because it means he has to keep (or download again) several previous versions of the huge kde tarballs - just to be able to revdep-rebuild a few small package whose data would actually be also contained in the current kde tarball. Of course, usually it is easy to get around this restriction: One can just make a copy of these packages in a personal overlay with a 3.5.5 version number (in some cases one also has to apply newer patch versions) - then the kde-3.5.5 tarballs are used. However, doing so brings the risk of missing possible security upgrades, e.g. kchechpass-3.5.0 -> kcheckpass-3.5.0-r1, since the version from the overlay is of course newer. So my enhancement suggestion is to put all current (in the example 3.5.5) versions of all kde-split packages in the portage tree even if their code did not change: This involves just a few packages anyway so that the (unnecessary but forced) recompilation of these packages won't hurt much. This also has the positive effect that you do not need to verify in new kde versions which packages have actually changed their code (and you minimize the risk of overlooking an actual code change which might of course lead to very subtle problems).