-
-
Notifications
You must be signed in to change notification settings - Fork 419
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ponyc rpm installs but compiler doesnt work libtinfo.so.5 error (ncurses package re-org) #1208
Comments
@Triangle345 i'm not aware of this being an issue. Sounds like a missing dependency of some sort. If you are able to track it down so we can fix for others, that would be awesome. |
So the issue is that on new versions of linux (like fedora 24) libtinfo.so.6 exists but 5 does not. So one remedy for this is to trick pony into thinking libtinfo.so5 exists. To my understanding libtinfo is part of the ncurses package. Simply create a sym link in /usr/lib and /usr/lib64 (depending on architecture):
Not sure how you guys want to handle this during rpm install though |
I'm not familiar with how the RPM builds happen at this point. @killerswan can you weigh in? |
The RPMs that get uploaded are built one of Travis's Ubuntu systems, using this make command: That is defined here: So the real magic is that FPM call at 697... Is there another package we can make the RPM require that'll provide the version of ncurses, or that library, we need? Or is this kinda cross-compiling from Ubuntu just not going to work very well here? |
Maybe just package version 5 of ncurses with the rpm/deb? On Sep 10, 2016 3:41 PM, "Kevin Cantú" notifications@github.com wrote:
|
This seems to be a problem for other compilers as well: |
Why isnt pony built statically to include everything? Sure the binary would On Wed, Sep 14, 2016 at 4:07 PM, Sylvan Clebsch notifications@github.com
|
We could add a dependency to "ncurses-devel" in the rpm package with -d flag ? Like :
|
Also I think that ponyc needs "openssl" and "pcre2" libraries. We could add these two dependencies to the rpm package with the same '-d' flag ? |
Even if adding a dependency to the rpm as you suggest, wont this still be On Thu, Sep 15, 2016 at 4:31 AM, Jean-Baptiste Petit <
|
Another option that i touched on a little bit, but is dirty and easy is to On Thu, Sep 15, 2016 at 6:31 AM, Eugene Feldman efeldman21@gmail.com
|
Well it seems that there is "libtinfo.so.5" in "ncurses-compat-libs" so instead of using |
that will work for fedora as of this moment but what happens when we have a Building it statically solves all these issues. On Thu, Sep 15, 2016 at 7:19 AM, Jean-Baptiste Petit <
|
And building statically open up an entire new host of issues as well. |
what sorts of issues are you thinking about, if I may ask? On Thu, Sep 15, 2016 at 11:31 AM, Sean T Allen notifications@github.com
|
statically linking all dependencies becomes a real issue when minor bug fix releases are done in the dependencies. its really problematic when it prevents easily upgrading to incorporate security fixes. i've worked at more than 1 place that had a policy against deploying applications that statically linked standard libraries like ncurses. |
I guess adding ncurses-compat-libs as a dep should work for awhile until On Fri, Sep 16, 2016 at 6:55 AM, Sean T Allen notifications@github.com
|
Does anyone know how to make |
Also, yes, |
hmm another option: On Wed, Sep 21, 2016 at 4:26 PM, Sylvan Clebsch notifications@github.com
|
So we should replace L657 by:
Something like that ? |
I've never used fpm before but the tag -d seems correct. However; dont you On Thu, Sep 22, 2016 at 6:09 PM, Jean-Baptiste Petit <
|
If I understand this correctly, now's a good time to figure out the version compat for RedHat and CentOS, and think about the naming a bit more. I'd like to get these new packages into the package conflicts, that is, so that only one of the following packages can be installed:
|
Although is the usability of these multiple packages really an improvement? |
While I'm kicking ideas around, is there a virtual package provided by both older distros' If there is no such virtual package, maybe we could set up the following 😜 :
Then on any of, say, Fedora 18, Fedora 24, CentOS 7, or RHEL 7 you'd install "ponyc-release" and get whichever dependencies Yum finds available... It seems like it may be a while before the latest RHEL, CentOS, and Fedora all provide the same version of ncurses-libs. |
Note: I'll come back to this in a little while. I've just stubbed my toe trying to take a CentOS install of rubygems from 2.0.14 to 2.0.15 so I can install FPM... |
I've now got the FPM stuff sorted out so I'm going to have another stab this afternoon. 😇 |
Hmm. |
@killerswan does the "Recommends" approach not work? That is, having a single package that tries to install ncurses-compat but doesn't strictly require it? |
I'm looking at taking since since it's marked as an "easy" bug. What's wrong with producing two or more rpms with different dependencies depending on the distribution targeted? It looks like .bintray.sh will find and upload both, so the change is limited to the makefile. Is everyone really set on having one package? |
Hmm, time for some more VM juggling to see if a single package which has the dependencies is even possible, like I was trying a while back. 😅 |
@gumpt thanks! perhaps ping @killerswan here and see what needs doing and what you can help with. |
@killerswan AFAIK rpms don't have the same "recommends" option that debs do, or at least FPM doesn't have a way to use it. I was going to use I'll go looking for another way to contribute. |
@gumpt if you are looking for things to take on, drop me an email. plenty of things that need doing, i'm sure we can find something that interests you. thanks! |
Regarding @sylvanc's "Recommends" suggestion: if I understand correctly (per old Stack Overflow conversations and the FPM docs), RPM doesn't support weak dependencies like that. There is, however, FPM's
If I understand correctly, we can make installation of all these work with a single install command (for
It's time for me to go sleep now, but these FPM commands make the packages I haven't yet tested on a Fedora install 😅 : fpm -s dir -t rpm -C build/ponyc-release-0.11.1-8888.922bed4 -p build/bin \
--name ponyc-release \
--provides ponyc \
--conflicts ponyc-master \
--version 0.11.1 \
--iteration "8889.922bed4" \
--description "The Pony Compiler" \
--depends ponydep-ncurses
fpm -s empty -t rpm -p build/bin \
--name ponydep-ncurses-libs-5-compat \
--conflicts ponydep-ncurses-libs-5 \
--provides ponydep-ncurses \
--version 2017.1 \
--iteration "4" \
--description "Virtual package for ncurses-compat" \
--depends "ncurses-compat-libs>=6"
fpm -s empty -t rpm -p build/bin \
--name ponydep-ncurses-libs-5 \
--conflicts ponydep-ncurses-libs-5-compat \
--provides ponydep-ncurses \
--version 2017.1 \
--iteration "4" \
--description "Virtual package for ncurses" \
--depends "ncurses<6" Once I've set up a repo and poked at these some more, what I imagine doing is making a quick @gumpt, you're right: what we probably should have done is made two packages a couple months ago, just to move things along. But here we are and I'm feeling motivated to learn how to do it the pretty way... |
It seems that I spoke too soon about weak dependencies: they can be specified now, although RPM ignores them, I'm not sure FPM can be used to add them, and I'm not sure either Yum or DNF does anything with them yet. But anyways using the "provides" feature like I was planning above, I've now got a pair of packages to play with at https://github.com/killerswan/ponydep-ncurses (building here, deploying here). That allows me to say I'm not sure this is working as I hoped. 😿 Both Yum and DNF choke here when installing on Fedora 25 (which needs the compat lib):
Maybe they'll use some smarter resolution logic when installing a package which depends on the virtual package than they do when installing literally that virtual package? But if not, then splitting the package ( |
Somewhat tangentially to all this, now I'm currently looking for advice about how basic Fedora package management is supposed to work. Behold this insanity (with my personal bintray repo which now has a ponyc-release 0.11):
Consistently I'm sure in like an hour all this will make sense but right now I'm puzzled! 😸 |
Yep, |
Victory is mine! On Fedora 25:
On CentOS 7:
Hooray!! 🍾 |
TODO:
|
@killerswan I believe that my merging #1680 closes this. If I was incorrect to close, please reopen. @Triangle345 when we do our next release, can you verify that the problem was fixed? |
Using fedora 24 kernel 4.6.6
I am able to install the rpm just fine. However; when running ponyc I get the following error
Is this a known issue or am I missing some other dependency?
The text was updated successfully, but these errors were encountered: