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

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

[Joshua Nichols]

It seems some of the VM vendors, mostly Sun and IBM, just love to
release new versions of their VMs, but without changing the filename
they get released as. In short, this means that it breaks our ebuilds,
because the instructions for getting the file are the same, but the file
it leads to is different, and therefore the digest breaks.

There are currently at least 3 bugs filed for this issue:

http://bugs.gentoo.org/show_bug.cgi?id=127204
http://bugs.gentoo.org/show_bug.cgi?id=123590
http://bugs.gentoo.org/show_bug.cgi?id=122220

There are a few solutions.

* 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.

* Have users rename the files. This is used in a few cases at least.
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.

* Some totally awesome way I haven't of yet.

Thoughts?

- Josh
-- 
gentoo-java@gentoo.org mailing list

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

[Miroslav Šulc]

[-- Attachment #1: Type: text/plain, Size: 2173 bytes --]

I don't see deep in the topic but I think the file should be renamed
somewhere.

1) It could probably be renamed at the source /distfiles/ directory, but
then there would be problem with the download from vendor where the file
has still the original name.
2) When ebuild downloads the file (with name given by vendor), it could
save it under another name to the /usr/portage/distfiles/ (or the file
could be renamed after it is downloaded). When user has to download the
file manually, he/she should be instructed to save the file as
/usr/portage/distfiles/file-name. It is important to download the fresh
file and not to use the old one laying somewhere on the disk.

I think it is not important what suffix will be appended to the file
name but it could be transparent to use release string (or something
other appropriate) from the ebuild name (something like "-r1") where the
new file is used the first time.

These are just thoughts, I don't know how the whole portage works.

Miroslav Šulc



Joshua Nichols napsal(a):
> It seems some of the VM vendors, mostly Sun and IBM, just love to
> release new versions of their VMs, but without changing the filename
> they get released as. In short, this means that it breaks our ebuilds,
> because the instructions for getting the file are the same, but the file
> it leads to is different, and therefore the digest breaks.
>
> There are currently at least 3 bugs filed for this issue:
>
> http://bugs.gentoo.org/show_bug.cgi?id=127204
> http://bugs.gentoo.org/show_bug.cgi?id=123590
> http://bugs.gentoo.org/show_bug.cgi?id=122220
>
> There are a few solutions.
>
> * 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.
>
> * Have users rename the files. This is used in a few cases at least.
> 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.
>
> * Some totally awesome way I haven't of yet.
>
> Thoughts?
>
> - Josh
>   

[-- Attachment #2: miroslav.sulc.vcf --]
[-- Type: text/x-vcard, Size: 349 bytes --]

begin:vcard
fn;quoted-printable:Miroslav =C5=A0ulc
n;quoted-printable:=C5=A0ulc;Miroslav
org:StartNet s.r.o.
adr;quoted-printable;quoted-printable:;;Schodov=C3=A1 309/10;Praha 5;;150 00;=C4=8Cesk=C3=A1 republika
email;internet:miroslav.sulc@startnet.cz
tel;cell:+420 603 711 413
x-mozilla-html:TRUE
url:http://www.startnet.cz
version:2.1
end:vcard

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

[Wiktor Wandachowicz]

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