Re: cygport patches for consideration

[Yaakov Selkowitz <yselkowitz@cygwin.com>]

On Tue, 2020-04-07 at 18:52 +0200, Achim Gratz wrote:
> Yaakov Selkowitz writes:
> > >     support subdirectories in CPAN download URL
> > 
> > There is no need for two variables to do the same thing.  I like
> > Reini's idea but let's call it CPAN_SUBDIR instead.  What about the
> > attached patch 0001?
> 
> Well, Reini's chimed in after he'd seen my patch and I just added that
> functionality on top of what was already implemented and in use by
> myself.  I guess I can change my cygport generator instead to use
> CPAN_DIR when needed, but haven't got around doing so.

Depending on its size, it would be nice to get this generator into
cygport's tools, and could possibly be used as the basis for other such
generators for other languages.

> > >     pkg_info.cygport: correct search order for Perl dependencies
> > 
> > Let's improve the auto-detection instead.  What about the attached
> > patch 0002?
> 
> Autodetection just doesn't work, with both false positives and negatives
> in spades.  Your proposed change probably produces more false negatives
> with not much change in the false positive rate.  So why bother?

This change would reduce the number of possible dependencies found by
only looking for those starting at the beginning of a line, which
should eliminate false positives from perldocs and optional deps.  So,
yes, some more false negatives, but also much less false positives. 
When would there be false positives in this case?

> There are actually multiple modules on CPAN attempting that sort of
> thing, one slower than the other and still none of them gets it right in
> all cases.  So your chances of doing better with a shell script are
> pretty much zero.  All Perl distributions come with metadata that tell
> you the dependencies among them already, so I just need a way to
> transfer that exactly into the cygport file (which again gets generated
> from that exact metadata, not written by hand).  By way of example,
> Cygwin has several packages that support Perl OO layers, of which there
> are many (Moose, Mouse, Moo, Mo…) so a dependency check pulling in all
> of them would end up creating a dependency chain that's at least 200
> more distributions.  Note that I very deliberately do not package Moose,
> which is huge.
> 
> > >     Automatically create a test release if the release string starts with a literal "0"
> > 
> > Nak.  There is not necessarily any correlation between a -0.* release
> > and whether it should be test or not.
> 
> Then there ought to be. :-)

No, not really.

> > >     Show pkg_tag in chatter
> > 
> > Pushed a slightly different approach to master.
> 
> I obviously like my patch better, because it keeps that line in the
> output no matter what the tag is (plus colors it so it's easier to catch
> a left over wrong tag when scrolling through the backlog).

Bikeshedding. :-)  There is an indication now of test:, which should
suffice.

> > Not sure what the
> > second part of that patch is supposed to be, however, as there is no
> > $pkg_testrelease variable in cygport.
> 
> That's a vestigial of some other patch that was ordered before this one
> before I created the branch, I think.

Will ignore then.

> > >     lib/src_install.cygpart: correct test in make_etc_defaults, possibly show diff
> > 
> > The first part is ok once the commit is reworded.  But when would a
> > user see the output of a postinstall script?
> 
> When looking in setup.log.full…  this output used to go to the console,
> but got axed quite some time ago.

Most people aren't going to check the log for that, nor does the log
allow them to do anything about it.

> > What would make more sense is to have a utility akin to "rpmconf -a"
> > on RPM-based systems which allows the user to compare existing files
> > with their /etc/defaults and choose if and how to merge the
> > differences.
> 
> Sure, but that's not cygport's business, no?

No, this would be something separate, or possibly part of cygutils. 
But's it's not the postinstall's business either AFAIAC.

--
Yaakov