Re: [PATCH setup 0/2] Detect filename collisions between packages

[Brian Inglis via Cygwin-apps]

On 2023-04-30 12:25, Jon Turney wrote:

On 28/04/2023 06:51, Brian Inglis wrote:

On 2023-04-27 10:11, Jon Turney wrote:

[...]
I think this functionality needs to exist in setup as well, though, as calm 
can't possibly have knowledge of packages you might be installing from 3rd 
party overlay package repositories.


Please make any of these conflict messages warnings only, as few packages use 
alternatives, and there may well be benign duplication, 


Your mention of 'alternatives' makes no sense to me.

The alternatives symlinks are not (and should not be) part of the package, but 
created or updated by postinstall scripts.


(It seems like it's impossible to make them work sensibly otherwise, as the link 
would be that from the most recently installed package (which could be any of 
the parallel installable alternatives), not the highest priority one.)



e.g. multiple language versions, as we normally get complaints about conflicts.


I don't know what this refers to.  Can you give an example?


As only a few packages use alternatives, and there may be multiple versions of 
packages for different language versions, e.g. python3... there may be some 
duplicate driver/selector file paths in some packages for different versions if 
they may be installed in parallel, and later versions do not obsolete earlier.


--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: how to contribute a noarch utility without porting Icon, Noweb, and Cygport

[Brian Inglis via Cygwin-apps]

On 2023-05-03 15:06, metaed wrote:

I want to contribute a Cygwin port of my utility program "dtt". It is an
architecture-independent executable written in Perl 5 plus a man page. It comes
with supplementary docs in /usr/share/doc, including the complete source.


The only known dtt out there seems to be an R package in CRAN for Discrete 
Trigonometric Transforms from another author.


So you might want to consider renaming your package to avoid any potential 
conflicts with CRAN if that was offered for Cygwin.


You would have to meet the criteria under:

https://cygwin.com/packaging-contributors-guide.html#submitting

and that nowadays requires a cygport build, producing valid "src" and "binary" 
packages meeting Cygwin standards including valid hint files, plus debuginfo 
packages if relevant, any Cygwin perl module and script requirements, and 
running checks to validate or verify the build.


You should provide at least the description of your package, with all required 
metadata, links to your sources and scripts, and why it would be a useful 
addition to Cygwin.


If available for Slack, links to slackbuilds, slack-desc, and info would help.


The package is built from source using the Noweb litprog tool, which also
requires the Icon programming language. Porting these to Cygwin could be a huge
undertaking. It would be much simpler for me to cross-compile, for lack of a
better term, where those tools are ported already -- namely, Slackware.


> Instead of porting Cygport to Slackware, again it would be much simpler for me
> to create the "binary" tarball and .hint file, a la
> , and upload manually to
> the noarch tree, a la .

> Is this an objectionable approach?

Some developers and maintainers use Fedora with Cygwin cross-compilers to build 
Cygwin and packages using cygport, which is a package of Bash scripts.
Unfortunately, there is little info about how to run Cygwin tools in a Linux 
environment.


Cygwin cooperates with and runs under Wine, so you could use that rather than 
Windows.


You would be providing the upstream sources, so you could provide the original 
and intermediate sources, with suitable cygport build.


You might also consider porting noweb3 to run under Cygwin lua, and provide that 
plus your package, with any adaptations required to build, install, check, and 
run them under Cygwin.


Using cygport is not very different from using any other distro packaging tools, 
being based on Gentoo portage, with cygport files providing definitions, and 
function overrides if required, similar to Slack slackbuilds, Gentoo ebuilds, 
Fedora specs, Debian control/rules, etc.


Check out what is required for a Perl package in a similar category at:

https://cygwin.com/cgit/cygwin-packages/?q=perl

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent

[Ken Brown via Cygwin-apps]

On 5/3/2023 8:19 AM, Ken Brown via Cygwin-apps wrote:
I wonder if those obsoleted packages are confusing setup.  In a new 
Cygwin installation, choosing only the base packages and cygport, setup 
wants to install perl-Test-Harness (and therefore perl 5.32).


I just tried a second experiment (with a new installation).  I chose 
base plus perl-Test-Harness.  Setup didn't report any problems; it 
simply added perl 5.32, and I let it complete the installation.  I then 
ran setup again, and the Pending view of the Select Packages page showed 
perl being upgraded to 5.36 and perl-Test-Harness being uninstalled.


So setup ended up doing the right thing with respect to the obsolete 
package, but it needed two passes.


Finally, I reran setup and chose cygport for installation.  This went 
through without a hitch.


Ken

how to contribute a noarch utility without porting Icon, Noweb, and Cygport

[metaed--- via Cygwin-apps]

I want to contribute a Cygwin port of my utility program "dtt". It is an
architecture-independent executable written in Perl 5 plus a man page. It comes
with supplementary docs in /usr/share/doc, including the complete source.

The package is built from source using the Noweb litprog tool, which also
requires the Icon programming language. Porting these to Cygwin could be a huge
undertaking. It would be much simpler for me to cross-compile, for lack of a
better term, where those tools are ported already -- namely, Slackware.

Instead of porting Cygport to Slackware, again it would be much simpler for me
to create the "binary" tarball and .hint file, a la
, and upload manually to
the noarch tree, a la .

Is this an objectionable approach?

Cheers!
Edward

Re: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent

[Achim Gratz via Cygwin-apps]

Achim Gratz via Cygwin-apps writes:
> Ken Brown via Cygwin-apps writes:
>> Could we work around the problem by removing the dependency of the
>> obsolete packages on perl5_032?
>
> Please don't.  I'll update automake soon.

Wait… these packages are not supposed to be dependent on the perl5_0xy
provides, the only Perl dependency should indeed be perl_base since no
version dependency is present.  Did the extra dependency on perl5_032
get auto-generated at some point?  Then please remove it from the hints.

I'll probably need to update the automake packages anyway since they
don't cleanly build anymore due to some changes in where the upstream
patches are.



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: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent

[Achim Gratz via Cygwin-apps]

Jon Turney via Cygwin-apps writes:
> Just adding just perl 5.36 to base seems to work fine.
>
> Adding cygport, pulls in automake-{12,13,14}, which depend on
> perl-Carp or perl-Test-Harness. I'm not sure why the solver then goes
> on to choose those packages, rather than perl_base which obsoletes
> them.

You may need to tell libsolv to reconsider the information it has based
on the chosen (default) solution.  THe solution it currently offers is
correct with both the intial information and the one after the solution
has been found, so there is no need for a satisfability solver to
continue.  If you were to use zypper you'd see several more solutions
offered and it can be quite hard to figure out without trying which one
is going to cause the least amount of changes.


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

Re: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent

[Achim Gratz via Cygwin-apps]

Ken Brown via Cygwin-apps writes:
> Could we work around the problem by removing the dependency of the
> obsolete packages on perl5_032?

Please don't.  I'll update automake soon.


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

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

Re: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent

[Ken Brown via Cygwin-apps]

On 5/3/2023 9:33 AM, Jon Turney wrote:

On 03/05/2023 13:19, Ken Brown via Cygwin-apps wrote:
I wonder if those obsoleted packages are confusing setup.  In a new 
Cygwin installation, choosing only the base packages and cygport, 
setup wants to install perl-Test-Harness (and therefore perl 5.32).  
Or maybe there's something else causing perl 5.32 to be chosen, but I 
don't see it.


Yeah, there's something weird going on there:

Just adding just perl 5.36 to base seems to work fine.

Adding cygport, pulls in automake-{12,13,14}, which depend on perl-Carp 
or perl-Test-Harness. I'm not sure why the solver then goes on to choose 
those packages, rather than perl_base which obsoletes them.


Could we work around the problem by removing the dependency of the 
obsolete packages on perl5_032?


Ken

Re: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent

[Jon Turney via Cygwin-apps]

On 03/05/2023 13:19, Ken Brown via Cygwin-apps wrote:

On 5/2/2023 4:45 PM, Achim Gratz via Cygwin-apps wrote:

Jon Turney via Cygwin-apps writes:

There's an updated report available [1], which should list the
affected packages.

[1] https://cygwin.com/packages/reports/perl_rebuilds.html


Thanks.  The newly obsolated packages (due to core now recent enough)
are still shown in this list (that's probably to be expected).


Ah, right.  That's probably a flaw in the logic used to generate this 
report, packages which are obsoleted by something else can just be ignored.


I wonder if those obsoleted packages are confusing setup.  In a new 
Cygwin installation, choosing only the base packages and cygport, setup 
wants to install perl-Test-Harness (and therefore perl 5.32).  Or maybe 
there's something else causing perl 5.32 to be chosen, but I don't see it.


Yeah, there's something weird going on there:

Just adding just perl 5.36 to base seems to work fine.

Adding cygport, pulls in automake-{12,13,14}, which depend on perl-Carp 
or perl-Test-Harness. I'm not sure why the solver then goes on to choose 
those packages, rather than perl_base which obsoletes them.

Re: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent

[Ken Brown via Cygwin-apps]

On 5/2/2023 4:45 PM, Achim Gratz via Cygwin-apps wrote:

Jon Turney via Cygwin-apps writes:

There's an updated report available [1], which should list the
affected packages.

[1] https://cygwin.com/packages/reports/perl_rebuilds.html


Thanks.  The newly obsolated packages (due to core now recent enough)
are still shown in this list (that's probably to be expected).


I wonder if those obsoleted packages are confusing setup.  In a new 
Cygwin installation, choosing only the base packages and cygport, setup 
wants to install perl-Test-Harness (and therefore perl 5.32).  Or maybe 
there's something else causing perl 5.32 to be chosen, but I don't see it.


Ken