New ebuild for xMule. Apparently fixes security holes in previous versions. Reproducible: Always Steps to Reproduce:
Created attachment 16707 [details] xmule-1.6.0a.ebuild xMule 1.6.0a ebuild.
Created attachment 16708 [details] ChangeLog ChangeLog update
Hi, I was aware of the fact that 1.6.0a was released but the tarball's name is still 1.6.0, so even with the 1.6.0 ebuild you get the 1.6.0a version and xmule 1.6.0 is in the tree already. I think it would be overkill to rename the ebuilds because 1.6.0a only has a cosmetic change in the preferences menu and nothing else (at least from what I can tell and after all, the new "version" uses the same tarball as the old one and in xmule sourcecode it still says 1.6.0 and not 1.6.0a, so this is only a "internal" change. Just merge 1.6.0 and you'll get the 1.6.0 tarball (which is handled as "1.6.0a", a new 1.6.0 tarball was uploaded but the sourceforge version information was changed to 1.6.0a). So, in fact, just emerge xmule-1.6.0 and all is fine ;)
Sorry, I sync from a cached portage tree which is at most 24 hours old, and xMule 1.4.3 was still newest (and masked). I think the ebuild name should always match the software version number exactly, or the user doesn't know _exactly_ what version they have installed.
yes, the only problem here is that the interal version (note the release version, you don't see anything about the "a" in the source code etc.) was changed but the name of the release tarball is still the same. But I renamed it to 1.6.0a now.
Just because they make a mistake with their naming, doesn't mean we have to follow suit :) The actual version of the software is what is important. Given then they have now changed to 1.6.0a, and 1.6.0 is no longer available, our ebuild should become 1.6.0a, and the old ebuild should be removed, (as i'm sure you have done). Thanks for the fast response :)
