perl_vendor

perl_vendor

[Achim Gratz]

Hi Reini,

I hope you don't mind that I move this discussion here, but it seems to
be the more appropriate place.


[Summary of previous discussion] I think that each perl module
distribution should have its own Cygwin package.  Since our perl
installation at work needs quite a few more distributions, I created the
missing cygport files while the switch to 5.14 was pending.  To ease
installation I also made a bundle package that does nothing but list all
those individual packages as dependencies so they can be installed
together by selecting a single package.


I am aware that splitting perl_vendor up into individual packages would
require great effort and I fully understand that you don't want to
shoulder that alone.  As a transitory measure with much less impact, the
distributions inside perl_vendor could each get empty packages that
depend on perl_vendor (sort of the reverse of what I've been doing with
my umbrella package), which would at least make it more explicit what is
available even though the install (and update) still happens en bloc.
If you like this idea better, I should be able to provide corresponding
Cygwin packages (or just the definitions, whatever your preference) in
about two weeks.

Moving a distribution out from perl_vendor into its own package later on
(LWP springs to mind, which is about the only distribution that I update
with some regularity) would require a coordinated release of two
packages, but that seems manageable.

As for taking over maintainership of all (or the majority) of these perl
distribution packages: I am open to the idea in general, but would want
to have a co-maintainer in the beginning and I would need access to a
build host at least for the XS modules.  The cygport definitions I have
in hand certainly need some more work before they would be good for
general release, but so far I've got zero feedback on them.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: perl_vendor

[Yaakov (Cygwin/X)]

On Sat, 2012-08-04 at 10:18 +0200, Achim Gratz wrote: 
> [Summary of previous discussion] I think that each perl module
> distribution should have its own Cygwin package.

Agreed wrt perl_vendor, although I'm not sure that we even need some of
these modules (unless they are just dependencies of others).  I would
start with the modules currently in perl_vendor before adding any others
that you need. 

> I am aware that splitting perl_vendor up into individual packages would
> require great effort and I fully understand that you don't want to
> shoulder that alone.  As a transitory measure with much less impact, the
> distributions inside perl_vendor could each get empty packages that
> depend on perl_vendor (sort of the reverse of what I've been doing with
> my umbrella package), which would at least make it more explicit what is
> available even though the install (and update) still happens en bloc.
> If you like this idea better, I should be able to provide corresponding
> Cygwin packages (or just the definitions, whatever your preference) in
> about two weeks.

I don't see any reason to do this.

> Moving a distribution out from perl_vendor into its own package later on
> (LWP springs to mind, which is about the only distribution that I update
> with some regularity) would require a coordinated release of two
> packages, but that seems manageable.

As long as you break up perl_vendor all at once, it will be.  Other
modules can be added later.

> As for taking over maintainership of all (or the majority) of these perl
> distribution packages: I am open to the idea in general, but would want
> to have a co-maintainer in the beginning and I would need access to a
> build host at least for the XS modules.  The cygport definitions I have
> in hand certainly need some more work before they would be good for
> general release, but so far I've got zero feedback on them.

cygport 0.11.0 should make it much easier to maintain this quantity of
Perl modules, since it can now generate setup.hint files with
appropriate requires: automatically.  I don't think Cygwin READMEs are
necessary for these either.

As for the .cygport files, they look good for the most part, but your
dependency checks could be replaced by the simpler DEPEND syntax.

Let me know if I can be of further assistance with this.


Yaakov

Re: perl_vendor

[Reini Urban]

On Sat, Aug 4, 2012 at 10:18 AM, Achim Gratz wrote:
> [Summary of previous discussion] I think that each perl module
> distribution should have its own Cygwin package.  Since our perl
> installation at work needs quite a few more distributions, I created the
> missing cygport files while the switch to 5.14 was pending.  To ease
> installation I also made a bundle package that does nothing but list all
> those individual packages as dependencies so they can be installed
> together by selecting a single package.
>
>
> I am aware that splitting perl_vendor up into individual packages would
> require great effort and I fully understand that you don't want to
> shoulder that alone.  As a transitory measure with much less impact, the
> distributions inside perl_vendor could each get empty packages that
> depend on perl_vendor (sort of the reverse of what I've been doing with
> my umbrella package), which would at least make it more explicit what is
> available even though the install (and update) still happens en bloc.
> If you like this idea better, I should be able to provide corresponding
> Cygwin packages (or just the definitions, whatever your preference) in
> about two weeks.

You can have all packages in vendor, but I doubt that they are all
needed and that
it is useful.
The reasoning for having them together was to support self-installation via CPAN
and reporting tests results automatically in case of errors, not to
bother the list with
such minor issues.

Splitting them up will break this idea. People will complain how to
install perl packages
and upstream maintainers will complain about missing cygwin feedback.

There are only some package with are not needed for CPAN and CPAN::Reporter,
which others found useful to have as default. DBI should be added also
IMHO, esp.
since using the default DBI from CPAN is still a security risk for
three quarters of a
year now.

What's the problem? Lack of upates for these?
Updates via cpan are easier than updates via setup.exe

> Moving a distribution out from perl_vendor into its own package later on
> (LWP springs to mind, which is about the only distribution that I update
> with some regularity) would require a coordinated release of two
> packages, but that seems manageable.
>
> As for taking over maintainership of all (or the majority) of these perl
> distribution packages: I am open to the idea in general, but would want
> to have a co-maintainer in the beginning and I would need access to a
> build host at least for the XS modules.  The cygport definitions I have
> in hand certainly need some more work before they would be good for
> general release, but so far I've got zero feedback on them.
-- 
Reini Urban
http://cpanel.net/   http://www.perl-compiler.org/

Re: perl_vendor

[Achim Gratz]

Reini Urban writes:
> What's the problem? Lack of upates for these?

My problem is that I need quite a bunch of additional Perl
distributions, I need to package them into Cygwin packages since they
will need to be installed with setup.exe and the way things are bundled
in perl_vendor makes dependency tracking more difficult.  I already have
a solution, I simply don't use perl_vendor and re-package everything I
need from it (essentially all of it, so the selection is quite sound).
That's what I linked to, I wasn't proposing that everything in this
bundle should go into Cygwin.

I won't bring this up again, I think everybody has said what they wanted
to say.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: perl_vendor

[Achim Gratz]

Yaakov (Cygwin/X) writes:
> cygport 0.11.0 should make it much easier to maintain this quantity of
> Perl modules, since it can now generate setup.hint files with
> appropriate requires: automatically.  I don't think Cygwin READMEs are
> necessary for these either.

Yes, I've seen your announcement and anticipate it will be a great help.
I won't be able to work on it during the next two or three weeks (or so
it seems), unfortunately.

> As for the .cygport files, they look good for the most part, but your
> dependency checks could be replaced by the simpler DEPEND syntax.

Hopefully yes.

> Let me know if I can be of further assistance with this.

Thanks, but let me get started first…


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: perl_vendor

[Reini Urban]

On Thu, Aug 30, 2012 at 11:28 AM, Achim Gratz wrote:
> Reini Urban writes:
>> What's the problem? Lack of upates for these?
>
> My problem is that I need quite a bunch of additional Perl
> distributions, I need to package them into Cygwin packages since they
> will need to be installed with setup.exe and the way things are bundled
> in perl_vendor makes dependency tracking more difficult.

Which one? I have no idea.
When you start proposing your stuff I can remove these packages
from perl_vendor.

But I still don't get the point. Now you have one dependency: perl_vendor.
With your scheme you have many dependencies.


> I already have a solution, I simply don't use perl_vendor and re-package everything I
> need from it (essentially all of it, so the selection is quite sound).
> That's what I linked to, I wasn't proposing that everything in this
> bundle should go into Cygwin.
>
> I won't bring this up again, I think everybody has said what they wanted
> to say.

You need to bring this up when you ITP them.
Because clashes are disallowed. You cannot provide the same files
with different packages.
-- 
Reini Urban
http://cpanel.net/   http://www.perl-compiler.org/

Re: perl_vendor

[Achim Gratz]

Reini Urban writes:
> When you start proposing your stuff I can remove these packages
> from perl_vendor.

I've been working on extracting the dependencies automatically given a
module or distribution name.  The method I started off with turned out
to be very slow and somewhat unreliable, so I bit the bullet and
re-implemented everything using CPAN and MetaCPAN.  I can't seem to
manage to use only one of the two… anyway, it's started working today
and it generates cygport "rpm-style" files with full descriptions and
everything, but needs to wait for Yaakov to release the next version of
cygport.  It will also tell you which cygwin packages need to be updated
and I hope to implement automatic editing of the cygport files later.

> But I still don't get the point. Now you have one dependency: perl_vendor.
> With your scheme you have many dependencies.

Yes and that is what I wanted.  With opaque bundles like perl_vendor I
need an extra step of mapping what is inside each bundle and I actually
need to look inside the source archive to find out, record it someplace
and then feed this information seperately to the dependency generator.

Note that I have nothing against transparent bundling, my local version
of perl_vendor is simply an empty package that depends on all the perl
distribution packages that comprise it.  I have more such bundles like
the statistics bundle that started this effort, another bundle for
additional distributions required for building and testing (only
developers will get these) and another one for some oddball stuff that
doesn't fit in either category, but should be installed almost
everywhere.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds