Re: New packages for review

[Greg Troxel <gdt%lexort.com@localhost>]

"David H. Gutteridge" <david%gutteridge.ca@localhost> writes:

> On Mon, 2020-02-10 at 07:10 +0000, voidpin wrote:

>> > I think LXQt needs more polish in its packaging to be on par with
>> > the stock installation experience of MATE, Xfce, LXDE, and others.
>> > As-is, it doesn't present an actual desktop environment an end user
>> > would expect by default.

>> This is a difficult one again and, I would say an upstream issue
>> really.  Prior to NetBSD, I was (still am) using Void Linux on top of
>> musl-libC (not GlibC). A philosophy (Void claims no philosophy) that
>> I've learned to really appreciate was, do not impose anything on the
>> end user. Although, I have to agree with your opinion, this is how
>> LXQt is provided by upstream.  Polishing the experience would require
>> installing/creating directories/copying files into the users home
>> directory. Personally, I'm against this but if you really find this
>> necessary maybe it could be considered. Although, I think we should
>> gather more opinions here on tech-pkg or pkgsrc-users mailing lists.
>
> Oh, I'm not advocating for installing anything to a user's home
> directory as a pkgsrc action. What I mean is, we're not necessarily
> fulfilling LXQt's expectations of default configuration, and that's why
> this disparity is occurring. Many upstream projects need to have their
> default configurations adjusted, since they often think "all the world's
> (mainstream) Linux". For example, LXQt thinks it should search for its
> window manager in /usr/bin, not in ${PREFIX}/bin.
>
> Have a look at x11/lxsession/Makefile, and you'll see an example of what
> I mean. It needed to be adjusted to match locations defined by pkgsrc. I
> expect LXQt will be similar, though I haven't had time to look into it.

I'm not 100% following here, but I think this is an interesting question
about pkgsrc quality standards, in terms of the bar to entry, and then
what we aspire to.  (However, as long as voidpin is improving things,
we're better off still in wip.)

Generally, we expect a package to build according to upstream's
recommendations, with things (that bear on packaging/installing) that
are upstream bugs fixed.  These include portability errors (test ==,
failure to handle other than Linux, relying on things not specified by
POSIX without a configure test, etc.).

There is also a class of changes where pkgsrc puts man pages perhaps
differently that others, and one can view upstream not haveing --mandir
as a bug.

I think hardcoding /usr/bin (vs $PREFIX/bin, or trusting PATH) is a bug
upstream, and deserves an upstream bug report; pkgsrc does have a notion
of filing upstream bugs and putting the URL/ref in patches (SUBST in
Makefile is basically a patch; if we are fixing something we shouldn't
need to, it doesn't matter how).

So I wonder if Dave thinks more than hardcoded /usr/bin needs fixing,
and if so, what?

(It does seem like there has been a vast amount of progress so far,
which is great!)