[gentoo-perl] CPAN ebuild moans and groans

[gentoo-perl] CPAN ebuild moans and groans

[Beau E. Cox]

Hi Michael et. al.

I have spent the last two days implementing an 'automatic'
CPAN module update system. I had a similar scheme when I
used Sorcerer and found it quite usefull. The idea is that
I maintain a mirror of CPAN with a daily rsync, and then
automatically build .ebuilds in my local PORTDIR, which then are
installed during the daily emerge --sync && emerge -uD world.
So far so good, but there are several bothersome gentoo
'conventions' I feel I want to air:

1) Who is it that made some CPAN builds lowercase (module-build,
not Module-Build, net-server not Net-Server)? Bad idea. It would
be easier (for my system, at least) to leave the names in the
CPAN form.

2) Lots of trouble with modules that indicate major versions
with 2 digits and minor revisions with four; Module-Build
for example:
  ...
  Module-Build-0.26
  Module-Build-0.2610
  Module-Build-0.2611
  Module-Build-0.27
  ...
I bypassed this problem by making my ebuild file names as
follows:
  Foo-Bar-1137143770.0.2611.ebuild
where 1137143770 is the 'epoch second' date of the tarball.
I can then be sure the order is correct and put code
in all ebuilds to get rid of the date-seconds:
  MY_PV=${PV:11}  and so on.

3) I pull my tarballs from my local mirror. I am using my
apache server to do this via SRC_URI="http://localhost/..."
But sometimes the request goes to my defined gentoo mirror
anyway. Why?

4) How about adding file:/// and rsync:// support for
SRC_URI?

-- 
Aloha => Beau;


-- 
gentoo-perl@gentoo.org mailing list

Re: [gentoo-perl] CPAN ebuild moans and groans

[Michael Cummings]

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

Hey there Beu,
> 1) Who is it that made some CPAN builds lowercase (module-build,
> not Module-Build, net-server not Net-Server)? Bad idea. It would
> be easier (for my system, at least) to leave the names in the
> CPAN form.

At one point, the power that was wanted all gentoo ebuilds to be lower
case. for a few months or so, dev-perl wasn't granted its 'grandfather'
clause in this regard, hence why there are a few lowercase modules (not
counting the ones that are legitimately lower case, like
dev-perl/version). the hassle involved in moving an ebuild has warranted
fixing the ones like module-build tbh.

> 2) Lots of trouble with modules that indicate major versions
> with 2 digits and minor revisions with four; Module-Build
> for example:
>   ...
>   Module-Build-0.26
>   Module-Build-0.2610
>   Module-Build-0.2611
>   Module-Build-0.27
>   ...
Blame portage, not us. For a while there at least (pretty sure its still
the case, but who wants to find out the bad way?), portage would get
confused by the length of the strings in re: the version numbers. Then
you have modules with _'s and -'s in the middle and it all goes to pot.

> I bypassed this problem by making my ebuild file names as
> follows:
>   Foo-Bar-1137143770.0.2611.ebuild
> where 1137143770 is the 'epoch second' date of the tarball.
> I can then be sure the order is correct and put code
> in all ebuilds to get rid of the date-seconds:
>   MY_PV=${PV:11}  and so on.
> 
ick

> 3) I pull my tarballs from my local mirror. I am using my
> apache server to do this via SRC_URI="http://localhost/..."
> But sometimes the request goes to my defined gentoo mirror
> anyway. Why?
because you don't have nomirror in your ebuilds most likely. src_uri is
used when the mirrors don't have something (or when the mirror is doing
the nightly fetches)

> 4) How about adding file:/// and rsync:// support for
> SRC_URI?

not a portage feature, you'd need to court the portage folks on that
one.

hope this helps - tree's a bit large and around for years, and what with
me mucking in for 3+ of those years, a lot of things that were required
and/or a good idea at the time we're just plain ol' stuck with now

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]