emerge -pl portage These are the packages that would be merged, in order: Calculating dependencies ... done! [ebuild U ] sys-apps/portage-2.2_rc18 [2.2_rc17] *portage-2.2_rc18 20 Dec 2008; Zac Medico <zmedico@gentoo.org> +portage-2.2_rc18.ebuild: 2.2_rc18 bump. This fixes bug #250902. This also includes all of the fixes that are in 2.1.6 through 2.1.6.2. 20 Dec 2008; Zac Medico <zmedico@gentoo.org> -portage-2.1.6.ebuild, -portage-2.1.6.1.ebuild, -portage-2.2_rc17.ebuild: Remove old versions. *portage-2.1.6.1 12 Dec 2008; Zac Medico <zmedico@gentoo.org> +portage-2.1.6.1.ebuild: 2.1.6.1 bump. This fixes bug #250148 (emerge hangs with selinux if ebuild spawns a daemon), bug #250166 (trigger download when generating manifest if file size differs from existing entry), and bug #250212 (new repoman upstream.workaround category for emake -j1 warnings). Bug #216231 tracks all bugs fixed since 2.1.4.x. [snip] Take a look at the 2.2_rc18 log entry, which refers the reader to the entry for 2.1.6.2. OK, now take a look at the 2.1.6.2 entry... Wait! Where is it? Ideally, --changelog would be smart enough to list 2.1.6.2 as well, but the ideal isn't always reasonable. Alternatively and perhaps a bit more reasonably, repoman could warn on such possible "forward" version references, with an overrule of course in case it interprets something entirely unrelated as a forward version reference. However, even that may well be impractical. If so, I suppose the humans may need to learn to reorder their commits without the aid of computer prompts, such that the references are to entries that show up. =:^) I do appreciate all that work you put into the changelog entries as I consider portage a core package and therefore follow the changelog quite religiously. (FWIW, that sort of concern for the user is a big reason I'm still a portage user. Unfortunately some of the alternatives... well, let's leave it where it was, there's a reason I'm still a portage user.) Of course, that makes it the more frustrating when there's a reference to some version that from what portage displays, hasn't even appeared yet. To date such hasn't been too big a deal as I've just run dep -j, which usually fills in the missing info. However, with udept now masked for removal due to dead upstream the problem is taking on new urgency. That suggests another simple semi-solution. If there was a way to tell --changelog to list from the top to the addition of the current installed version (which seems to be what udept does) instead of just the supposedly affected range, thus covering both downgrade-mask changelog entries (if present) and this sort of situation, it'd solve the problem. Of course, one can manually look up the category, verify the repository, and cat/head the /entire/path/to/repo/cate-gory/package/Changelog, but that's a lot of work of the type that computers are especially good at automating away. (From the udept package-masking thread on gentoo-dev, it seems gentoolkit will pickup this functionality, but it'd be useful in portage too, either as a secondary option related to emerge --changelog, or possibly as an added epkginfo option.) TIA, Duncan
I've updated the order of the changelog entries so it should behave better now. (In reply to comment #0) > Ideally, --changelog would be smart enough to list 2.1.6.2 as well, but the > ideal isn't always reasonable. Alternatively and perhaps a bit more > reasonably, repoman could warn on such possible "forward" version references, > with an overrule of course in case it interprets something entirely unrelated > as a forward version reference. However, even that may well be impractical. If > so, I suppose the humans may need to learn to reorder their commits without the > aid of computer prompts, such that the references are to entries that show up. > =:^) I think that checking for forward version references would be too error prone. As it is, the code only has to recognize the lines that begin with a * character, and nothing more. I'd prefer to keep it that way. > That suggests another simple semi-solution. If there was a way to tell > --changelog to list from the top to the addition of the current installed > version (which seems to be what udept does) instead of just the supposedly > affected range, thus covering both downgrade-mask changelog entries (if > present) and this sort of situation, it'd solve the problem. I suppose we could make a separate action for that but maybe it's better left to gentoolkit.
Cleaning out my open bug list. AFAIK this is long obsolete, so close it as such.
