Package cleanup

[Jay McCarthy]

If you go to the package site now, then every package table will tell
you how many of the packages shown have some sort of flaw. The flaws
are: failing to build, tests failing, missing documentation, missing
tags, or missing a description. (We need to fix it a little bit
because some packages aren't supposed to have docs, like
web-server-lib, because its docs are in web-server-doc.)

Conor Finegan implemented this. Good job!

--
-=[ Jay McCarthy http://jeapostrophe.github.io ]=-
-=[ Associate Professor PLT @ CS @ UMass Lowell ]=-
-=[ Moses 1:33: And worlds without number have I created; ]=-

[Neil Van Dyke]

In case anyone is as mentally slow as I am right after lunch: I think
this is the gray button labeled like: "515 todos. Click here to see them."

Would it be good to have an automated monthly email to package owners,
itemizing the issues with each of their packages? (Each email address
would get no more than one email a month, and there would be no email to
an address when none of their packages had issues.)

[Jay McCarthy]

Yup, we may do that eventually, but we won't start spamming without permission.

Jay

> --
> You received this message because you are subscribed to the Google Groups
> "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-dev+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-dev/7de48c78-7535-c47c-e29e-4338f8426e4b%40neilvandyke.org.
> For more options, visit https://groups.google.com/d/optout.

[John Clements]

> On Jul 12, 2017, at 17:50, Jay McCarthy <jay.mc...@gmail.com> wrote:
>
> Yup, we may do that eventually, but we won't start spamming without permission.

I have a bunch of packages that fail because they depend on external libraries, viz: GLPK, which depends on the glpk library. It’s listed as having failing tests, because (not surprisingly) it won’t run without the library installed. Do we have a story, here, or should I just leave these the way they are? Forgive me if I’ve missed relevant discussion.

John

[Matthew Flatt]

At 12 Jul 2017 16:43:48 -0400, "'John Clements' via Racket Developers" wrote:
> I have a bunch of packages that fail because they depend on external
> libraries, viz: GLPK, which depends on the glpk library. It’s listed
> as having failing tests, because (not surprisingly) it won’t run
> without the library installed. Do we have a story, here, or should I
> just leave these the way they are? Forgive me if I’ve missed relevant
> discussion.

For the current options, see "Dealing with Test Failures" and "Working
with Native Libraries" at

https://pkg-build.racket-lang.org/about.html

which is the page that you get from "About" -> "Package Builds" at
pkgs.racket-lang.org.

[Leif Andersen]

It looks like this is what the docs have to say wrt making tests pass:
```
Distribute Native Libraries

Another option is to build a 64-bit Linux version of the library,
distribute it as a package, and make the package a platform-specific
dependency of your package for the "x86_64-linux-natipkg" platform.

This option is in many ways the best one for users and for
testing—especially if Windows and Mac OS native-library packages are
also provided—but it’s more work.
```

This isn't enough though, we need to know what distro to target. Even
in situations where I would love to bundle native packages, these can
have a large amount of dependencies that are specific to individual
distros.


~Leif Andersen

> --
> You received this message because you are subscribed to the Google Groups "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/59668b21.d995620a.8b570.95a4SMTPIN_ADDED_MISSING%40gmr-mx.google.com.

[Matthew Flatt]

At Wed, 12 Jul 2017 17:25:58 -0400, Leif Andersen wrote:
> It looks like this is what the docs have to say wrt making tests pass:
> ```
> Distribute Native Libraries
>
> Another option is to build a 64-bit Linux version of the library,
> distribute it as a package, and make the package a platform-specific
> dependency of your package for the "x86_64-linux-natipkg" platform.
>
> This option is in many ways the best one for users and for
> testing—especially if Windows and Mac OS native-library packages are
> also provided—but it’s more work.
> ```
>
> This isn't enough though, we need to know what distro to target. Even
> in situations where I would love to bundle native packages, these can
> have a large amount of dependencies that are specific to individual
> distros.

For the "natipkg" strategy, you would need build and supply all of
those dependencies, too --- or depend on other "natipkg" packages that
supply them.

Granted, you'll need to depend on some C library, but picking a
sufficiently old one works in practice. The existing "natipkg" binaries
are built on Debian Lenny for that reason.

To the degree that this strategy doesn't work, then I think we should
just say that the "natipkg" idea doesn't work instead of trying to pick
a distribution.

[Jack Firth]

Do the "missing documentation" todos take into account packages that have

 their docs provided by other packages? e.g. a "foo-lib" package documented
in a "foo-doc" package. If not, perhaps there could be some special info.rkt

 field to mark other packages that provide documentation for a package without

its docs directly included.