deb.sury.org
deb.sury.org copied to clipboard
oerdnj
Can not install lighttpd anymore
If I try to install lighttpd on Debian Stretch, I will get following error: The following packages have unmet dependencies: lighttpd : Depends: libssl1.1 (>= 1.1.0) but it is not going to be installed E: Unable to correct problems, you have held broken packages.
We run into the same issue. The libssl1.1 version from deb.sury.org breaks Lighttpd start.
E.g. Debian Stretch ship a current enough version of it + related OpenSSL version, so solution currently is to block the ones from sury.org:
echo -e '# libssl1.1 from sury.org breaks Lighttpd install
Package: openssl libssl1.1\nPin: origin packages.sury.org\nPin-Priority: -1' > /etc/apt/preferences.d/openssl
this are not solution.. jessie are still LTS for some years and packages for survey does not install, that break/conflict are innnecesary due the backported ssl library.. the php must ajust to build with jessie backports ssl lib
there's a conflict with libssl that makes unnistalable and break a lot of packages in jessie... including lighttpd.. i made a updated package for lighttp if you interesting can upload to your repo the work: https://build.opensuse.org/package/show/home:vegnuli:devel/lighttpd
anounce here for those that need lighty+php7 : https://vegnuli.wordpress.com/2019/06/21/paquetes-deb-lighttpd-actualizado-y-backportado-con-urls-estrictas-soportadas/
@mckaygerhard
Thanks for your Lighttpd build!
But hmm how can this be an issue on Jessie? There is no libssl1.1 package available in the official Jessie repo, so nothing that should be able to conflict?
On Jessie it's libssl1.0.0, but this is not available in the sury.org repo as far as I could see.
Or can an installed libssl1.1 package conflict with an installed libssl1.0.0 package? Would be at least new to me (we install both all the time without issues), since they place different files/dirs as well.
EDIT: Ah perhaps it's the openssl package? Doing the same than above, just with this package (allowing the libssl1.1 install), should work: https://github.com/oerdnj/deb.sury.org/issues/1056#issuecomment-492392402
It is as well not pulled in as dependency or required by any PHP package, just auto-upgraded in case of sufficient priority.
@oerdnj
PHP must
This is just wording 😉. Nice to have a compatible and updated Lighttpd package offered here, that's it 😃.
But one question, why is this libssl1.1 package/version actually shipped with the repo? I could not find any other package (in the sury.org Stretch branch) that requires the libssl1.1 version that is shipped. All of them have fulfilled dependencies with the one from the official Debian repo, and so the above workaround to block those packages from sury.org simply works well for us, at least with full PHP7.2 and PHP7.3 installs.
As said, on Jessie it makes sense, since there libssl1.1 is not available in official repo, and because of this I am wondering how any conflicts can even occur 🤔. Regardless, we have now workarounds collected here for every case.
People requested TLS 1.3 (for nginx and apache2) and I just cannot afford maintaining multiple OpenSSL versions.
Ah perhaps it's the openssl package?
I am (should be) stripping building of openssl packages on older platforms.
This is just wording
Everything is just a wording and still people usually prefer to communicate in a polite way among themselves.
@oerdnj
People requested TLS 1.3
Ah okay, this makes sense then.
I am (should be) stripping building of openssl packages on older platforms.
If libssl is offered, it generally makes sense to me to offer compatible/related -dev/-doc/-.. and openssl packages as well (as it is now). On the other hand, if this causes conflicts and is not required/used by PHP itself, you are probably right.
Actually, when the intention for libssl (on Stretch) is to have TLS1.3 support for webservers, it could be removed from the PHP repo, as it is available in the Apache2 and Nginx repos already? If one adds one of those two, surely Lighttpd is not a topic anyway, so no conflict. Would clean things up a bid as well, so only have packages in the repo that are required to fulfil dependencies or directly enable features that are most likely wanted (current Apache2/Nginx => TLS1.3).
Everything is just a wording and still people usually prefer to communicate in a polite way among themselves.
I mean written text can easily be misunderstood (when it's about the mood), or people tend to shorten things or simply have a limited set of words (no native English speakers). So somethings things "sound" more forcing or impolite then meant or how they would have spoken face-to-face.
hi @oerdnj seems that as i know we need made packags take in consideration original main line of the packages! not introducing so many newer breaks possible! for that just we upgraded to testing...
not always and now today more often.. can be possible to upgrade to "last" next piece of the software, by example n muy very ancient BUT WORKING PERFECTLY AMD K7 the framegraabber was removed from kernel since 2,6.18 and now since many many years i cannot use more modern linux in that powered machine ...
well @MichaIng .. that you said sound like "i use the most powered cos i can.. if you cannot sorry for you"
i already explained in previous parragraf.. not always can be upgraded a group of software.. i made the lighttpd package due was easy.. but obviusly more easy was not forced the libssl package to made conflicts with older jessie in release
i understand @oerdnj tha seems you just "recompile and rebuild with XXXX" but please can you take in consideration the limitations of the current release in future rebuilds of your packages? removing the libssl conflict and investigate why that happened are not so difficult..
thanks for packages in any way!
it could be removed from the PHP repo
Any kludge or workaround makes things more complicated and more prone to error. Don't forget this is an effort I only do in my already scarce free time. That's why I want all the libraries unified across the repositories.
I also believe (but haven't tested it myself) that PHP hands over the handshake to libssl, so TLS 1.3 is supported because the connection handling is done by OpenSSL and PHP doesn't need to know anything about it.
So somethings things "sound" more forcing or impolite then meant or how they would have spoken face-to-face.
Which means that extra caution must be taken when communicating with other people on the Internet, not the vice versa. And also perhaps don't ever use exclamation marks...
@mckaygerhard Generally I think it is not part of the scope to resolve every conflict with any other software that is shipped with the official repo. You would end up having a bunch of additional packages and as a rats tail probably when starting to use the repo, users wonder why half of their system is upgraded, causing more issue than it solves 😄. And the maintenance to build+keep all of them up to date of course is the main reason.
IMO less is more here and as in my last post might even solve all conflicts already: No openssl package on the Jessie branch and no libssl1.1 (+dev/dev/openssl) at all on the PHP/Stretch branch would at least resolve all mentioned conflicts here. However I am not able to consider all cases/needs 😉. TLS1.3 would then be enabled via Apache2 and Nginx branches, which would most likely not be added in combination with Lighttpd.
as you said preciselly @MichaIng ... as example the conlfict was a little thing.. if i just rebuild the lightty package you and others cannot use it! you know it? that'0s wahy "just rebuild packages" are not a task.. the work must be made in right way!
JFTR Maintaining yet another package (that I don't even use) is not a little thing, but additional burden. @mckaygerhard, please, just stop making these absurd claims. This repository just doesn't support lighttpd and while it's sad to throw lighttpd users under the bus, the community is niche, and there are ways around it (just put one or the other thing into separate minimal chroot).
umm well ok, but apache2 its not just the "most fancy efficient web server", that's why the issue here!
commonly proffessional setups including have a lightty in front.. with reverse proxyes to ngynx/apache2 for the rest...