tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: devel/cmake patch



> On Jul 7, 2018, at 12:16 PM, Greg Troxel <gdt%lexort.com@localhost> wrote:
> 
> 
> Brook Milligan <brook%nmsu.edu@localhost> writes:
> 
>>> On Jul 7, 2018, at 10:08 AM, Patrick Welche <prlw1%cam.ac.uk@localhost> wrote:
>>> 
>>> On Sat, Jul 07, 2018 at 07:55:35AM -0600, Brook Milligan wrote:
>>>> I do, however, know that on this system, which is a major
>>>> supercomputing center that would be nice to have pkgsrc working
>>>> for, I have identified a problem and the underlying reason (ncurses
>>>> v. curses).  I hope we can identify how to fix the Makefile for
>>>> this to work out of the box.
>>> 
>>> Reminds me of
>>> 
>>> https://mail-index.netbsd.org/pkgsrc-users/2018/06/28/msg027080.html
>>> 
>>> which was solved with a
>>> 
>>> sudo apt install libncurses5-dev
>>> 
>>> Presumably that isn't enough?
>> 
>> Thanks for the pointer.  However, I am uncertain why a solution for
>> pkgsrc would involve an apt install.  Isn't the point to set all the
>> requirements in the pkgsrc Makefiles so that "it just works"?  Maybe I
>> don't understand the underlying context of the email thread you are
>> referring to.
> 
> The basic question is what the environment pkgsrc expects at bootstrap
> (and for that bootstrap to be usable on some other system).  This should
> be explained in bootstrap/README.Linux :-) It is to some extent -- and
> even says to install libncurses5-dev, but it needs a prereq section for
> RHEL, and probably to say something about distributions not related to
> Debian or RHEL.   And arguably bootstrap should check and fail if the
> required stuff is not present.

OK, thanks for the reminder.  However ...

It seems that reducing the prerequisites would be a generally useful goal for pkgsrc.  Why is it not appropriate to depend on a package that will solve the problem rather than requiring a general prerequisite for all of pkgsrc?

In my particular case, this matters a lot.  I can see why requiring use of something like apt-get or yum on a personal Linux system might make sense, even if it adds a (certainly in this case) needless layer of complication and creates an unnecessary barrier to uptake.  However, that requirement creates an extreme hurdle for users of large server systems that do not have such tools installed but still need to customize software environments via pkgsrc.  It is challenging enough (and should be made simpler) to use pkgsrc to build suitable software environments on such systems.  Imposing an additional requirement of figuring out how to get another system, e.g., apt or yum, installed for a few prerequisites is untenable.  This makes even less sense in a case such as this where pkgsrc already includes both the required package (ncurses) and the means to selectively depend on it when necessary (INCOMPAT_CURSES).

Is there evidence that we cannot have appropriate packages make use of INCOMPAT_CURSES instead of requiring an ncurses-devel prerequisite?  Wouldn't the "libncurses not installed" section of [1] be improved if it said something to the effect of "tell us so we can fix the package and define INCOMPAT_CURSES as a workaround"?

Are we in agreement that reducing prerequisites for pkgsrc is a worthy goal?

Cheers,
Brook

[1] http://wiki.netbsd.org/pkgsrc/how_to_use_pkgsrc_on_linux/




Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



Home | Main Index | Thread Index | Old Index