[gentoo-java] Re: dealing with VM vendors that don't change distfiles names

[Wiktor Wandachowicz <siryes@gmail.com>]

Joshua Nichols <nichoj@...> writes:

> Thoughts?

There's nothing I can think of that wouldn't interfere with how portage
deals with the downloads right now... :-( 

> * Have users rename the files. This is used in a few cases at least.

When the file must be downloaded manually, it's not a big deal.
It was clearly documented last time when the jdk docs got the -r1 suffix.
Unexpected, intriguing, but went smooth anyway (at least in my case).

> This leads to the question of how to version the ebuilds though, because
> they don't follow a sane (to us) versioning scheme, ie GA, SR-1, SR-2, etc.

Hummm... Add the date when the change occured? (like with old Wine?)

> * Just redigest the ebuild with the new distfile. This would be the
> quickest solution, but it'd be problematic because then the digest would
> be broken for people that already have the distfiles.
> 
> * Some totally awesome way I haven't of yet.
> 

Maybe instead put the "known" digest in the ebuild(s) or eclass, write the
necessary function(s) in eclass(es) or hack portage /again/, and finally do
some voodoo on the user's side to rename the downloaded files as desired.

* If the digest of the file happens to be "unknown", because the user didn't
  do 'emerge --sync' yet (thus: old ebuild, no new "known" digests, updated
  download - or partial), then print an error and abort.

* If the required file already exist in 'distfiles' and the digest detects
  that this is the "old" version, rename it and download the new file
  (with optional rename).

I'm afraid that the above mockup is completely inconsistent with the current
portage behaviour. Digesting, checking, downloading (but: no renaming) is
right now automatic and doesn't handle the above scenarios... yet! ;-)

But this *might* work. Although I cannot proove it... :-/

Friendly,

-- 
gentoo-java@gentoo.org mailing list