Defining multiple library dependencies
Clash Royale CLAN TAG#URR8PPP
I am trying to install FreeRadius 3.0.16 in Debian 9 from my local repository.
However when trying to install it I got this error:
The following packages have unmet dependencies:
freeradius : Depends: libssl1.0.0 (>= 1.0.1e-2+deb7u5) but it is not installable
The culprit is in the original source code at freeradius-server/debian/rules:
# Add dependency on distribution specific version of openssl that fixes Heartbleed (CVE-2014-0160).
ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
SUBSTVARS = -Vdist:Depends="libssl1.0.0 (>= 1.0.1f-1ubuntu2)"
else
SUBSTVARS = -Vdist:Depends="libssl1.0.0 (>= 1.0.1e-2+deb7u5)"
endif
Putting it checking for Debian 9 is not the ideal situation, as it can be compiled for several Debian flavours...
So, short of checking for the Debian version, is there any alternative of defining the Depends for Debian both and as an alternative depending on libssl1.1 (>= 1.1)?
debian packaging
edited Aug 16 '17 at 14:10
Stephen Kitt
167k24373452
asked Aug 16 '17 at 13:49
Rui F RibeiroRui F Ribeiro
39.5k1479132
add a comment |
I am trying to install FreeRadius 3.0.16 in Debian 9 from my local repository.
However when trying to install it I got this error:
The following packages have unmet dependencies:
freeradius : Depends: libssl1.0.0 (>= 1.0.1e-2+deb7u5) but it is not installable
The culprit is in the original source code at freeradius-server/debian/rules:
# Add dependency on distribution specific version of openssl that fixes Heartbleed (CVE-2014-0160).
ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
SUBSTVARS = -Vdist:Depends="libssl1.0.0 (>= 1.0.1f-1ubuntu2)"
else
SUBSTVARS = -Vdist:Depends="libssl1.0.0 (>= 1.0.1e-2+deb7u5)"
endif
Putting it checking for Debian 9 is not the ideal situation, as it can be compiled for several Debian flavours...
So, short of checking for the Debian version, is there any alternative of defining the Depends for Debian both and as an alternative depending on libssl1.1 (>= 1.1)?
debian packaging
edited Aug 16 '17 at 14:10
Stephen Kitt
167k24373452
asked Aug 16 '17 at 13:49
Rui F RibeiroRui F Ribeiro
39.5k1479132
1
Is that piece of code something you added? If so, why do you want to enforce the Heartbleed fix in your FreeRADIUS package? (I can understand why you’d want to do this, but typically you’d enforce “being up-to-date” through other means; this is not something you’d expect in a package, which is why the packaging tools don’t provide for it very well.)
– Stephen Kitt
Aug 16 '17 at 14:00
@StephenKitt The code is verbatim as in the official git repo.
– Rui F Ribeiro
Aug 16 '17 at 14:02
add a comment |
I am trying to install FreeRadius 3.0.16 in Debian 9 from my local repository.
However when trying to install it I got this error:
The following packages have unmet dependencies:
freeradius : Depends: libssl1.0.0 (>= 1.0.1e-2+deb7u5) but it is not installable
The culprit is in the original source code at freeradius-server/debian/rules:
# Add dependency on distribution specific version of openssl that fixes Heartbleed (CVE-2014-0160).
ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
SUBSTVARS = -Vdist:Depends="libssl1.0.0 (>= 1.0.1f-1ubuntu2)"
else
SUBSTVARS = -Vdist:Depends="libssl1.0.0 (>= 1.0.1e-2+deb7u5)"
endif
Putting it checking for Debian 9 is not the ideal situation, as it can be compiled for several Debian flavours...
So, short of checking for the Debian version, is there any alternative of defining the Depends for Debian both and as an alternative depending on libssl1.1 (>= 1.1)?
debian packaging
edited Aug 16 '17 at 14:10
Stephen Kitt
167k24373452
asked Aug 16 '17 at 13:49
Rui F RibeiroRui F Ribeiro
39.5k1479132
I am trying to install FreeRadius 3.0.16 in Debian 9 from my local repository.
However when trying to install it I got this error:
The following packages have unmet dependencies:
freeradius : Depends: libssl1.0.0 (>= 1.0.1e-2+deb7u5) but it is not installable
The culprit is in the original source code at freeradius-server/debian/rules:
# Add dependency on distribution specific version of openssl that fixes Heartbleed (CVE-2014-0160).
ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
SUBSTVARS = -Vdist:Depends="libssl1.0.0 (>= 1.0.1f-1ubuntu2)"
else
SUBSTVARS = -Vdist:Depends="libssl1.0.0 (>= 1.0.1e-2+deb7u5)"
endif
Putting it checking for Debian 9 is not the ideal situation, as it can be compiled for several Debian flavours...
So, short of checking for the Debian version, is there any alternative of defining the Depends for Debian both and as an alternative depending on libssl1.1 (>= 1.1)?
debian packaging
debian packaging
edited Aug 16 '17 at 14:10
Stephen Kitt
167k24373452
asked Aug 16 '17 at 13:49
Rui F RibeiroRui F Ribeiro
39.5k1479132
edited Aug 16 '17 at 14:10
Stephen Kitt
167k24373452
asked Aug 16 '17 at 13:49
Rui F RibeiroRui F Ribeiro
39.5k1479132
edited Aug 16 '17 at 14:10
Stephen Kitt
167k24373452
edited Aug 16 '17 at 14:10
Stephen Kitt
167k24373452
edited Aug 16 '17 at 14:10
Stephen Kitt
167k24373452
167k24373452
asked Aug 16 '17 at 13:49
Rui F RibeiroRui F Ribeiro
39.5k1479132
asked Aug 16 '17 at 13:49
Rui F RibeiroRui F Ribeiro
39.5k1479132
asked Aug 16 '17 at 13:49
Rui F RibeiroRui F Ribeiro
39.5k1479132
39.5k1479132
1
Is that piece of code something you added? If so, why do you want to enforce the Heartbleed fix in your FreeRADIUS package? (I can understand why you’d want to do this, but typically you’d enforce “being up-to-date” through other means; this is not something you’d expect in a package, which is why the packaging tools don’t provide for it very well.)
– Stephen Kitt
Aug 16 '17 at 14:00
@StephenKitt The code is verbatim as in the official git repo.
– Rui F Ribeiro
Aug 16 '17 at 14:02
add a comment |
1
Is that piece of code something you added? If so, why do you want to enforce the Heartbleed fix in your FreeRADIUS package? (I can understand why you’d want to do this, but typically you’d enforce “being up-to-date” through other means; this is not something you’d expect in a package, which is why the packaging tools don’t provide for it very well.)
– Stephen Kitt
Aug 16 '17 at 14:00
@StephenKitt The code is verbatim as in the official git repo.
– Rui F Ribeiro
Aug 16 '17 at 14:02
1
1
Is that piece of code something you added? If so, why do you want to enforce the Heartbleed fix in your FreeRADIUS package? (I can understand why you’d want to do this, but typically you’d enforce “being up-to-date” through other means; this is not something you’d expect in a package, which is why the packaging tools don’t provide for it very well.)
– Stephen Kitt
Aug 16 '17 at 14:00
Is that piece of code something you added? If so, why do you want to enforce the Heartbleed fix in your FreeRADIUS package? (I can understand why you’d want to do this, but typically you’d enforce “being up-to-date” through other means; this is not something you’d expect in a package, which is why the packaging tools don’t provide for it very well.)
– Stephen Kitt
Aug 16 '17 at 14:00
@StephenKitt The code is verbatim as in the official git repo.
– Rui F Ribeiro
Aug 16 '17 at 14:02
@StephenKitt The code is verbatim as in the official git repo.
– Rui F Ribeiro
Aug 16 '17 at 14:02
add a comment |
1 Answer
1
active
oldest
votes
I would just remove those lines of code; it’s not up to individual packages to force security upgrades in other packages.
If you look at the Debian package’s rules, you’ll see it doesn’t have anything like this. In any case, as you point out the dependencies can’t work on Debian 9 since that uses a different package name for OpenSSL.
(It should be possible to work out a disjunction which would enforce the right package upgrades, but I don’t think it’s worth the effort.)
answered Aug 16 '17 at 14:09
Stephen KittStephen Kitt
167k24373452
It makes sense, going to propose a patch without those lines. Thanks.
– Rui F Ribeiro
Aug 16 '17 at 14:15
(Although those rules will prevent running FR in the recent Debian and derivates, the changes were not approved. I still understand their point of view, the bigger problem is Debian not having a maintainer for FR )
– Rui F Ribeiro
Aug 21 '17 at 10:56
You could join the maintenance team ;-).
– Stephen Kitt
Aug 21 '17 at 11:31
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f386442%2fdefining-multiple-library-dependencies%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I would just remove those lines of code; it’s not up to individual packages to force security upgrades in other packages.
If you look at the Debian package’s rules, you’ll see it doesn’t have anything like this. In any case, as you point out the dependencies can’t work on Debian 9 since that uses a different package name for OpenSSL.
(It should be possible to work out a disjunction which would enforce the right package upgrades, but I don’t think it’s worth the effort.)
answered Aug 16 '17 at 14:09
Stephen KittStephen Kitt
167k24373452
It makes sense, going to propose a patch without those lines. Thanks.
– Rui F Ribeiro
Aug 16 '17 at 14:15
(Although those rules will prevent running FR in the recent Debian and derivates, the changes were not approved. I still understand their point of view, the bigger problem is Debian not having a maintainer for FR )
– Rui F Ribeiro
Aug 21 '17 at 10:56
You could join the maintenance team ;-).
– Stephen Kitt
Aug 21 '17 at 11:31
add a comment |
I would just remove those lines of code; it’s not up to individual packages to force security upgrades in other packages.
If you look at the Debian package’s rules, you’ll see it doesn’t have anything like this. In any case, as you point out the dependencies can’t work on Debian 9 since that uses a different package name for OpenSSL.
(It should be possible to work out a disjunction which would enforce the right package upgrades, but I don’t think it’s worth the effort.)
answered Aug 16 '17 at 14:09
Stephen KittStephen Kitt
167k24373452
It makes sense, going to propose a patch without those lines. Thanks.
– Rui F Ribeiro
Aug 16 '17 at 14:15
(Although those rules will prevent running FR in the recent Debian and derivates, the changes were not approved. I still understand their point of view, the bigger problem is Debian not having a maintainer for FR )
– Rui F Ribeiro
Aug 21 '17 at 10:56
You could join the maintenance team ;-).
– Stephen Kitt
Aug 21 '17 at 11:31
add a comment |
I would just remove those lines of code; it’s not up to individual packages to force security upgrades in other packages.
If you look at the Debian package’s rules, you’ll see it doesn’t have anything like this. In any case, as you point out the dependencies can’t work on Debian 9 since that uses a different package name for OpenSSL.
(It should be possible to work out a disjunction which would enforce the right package upgrades, but I don’t think it’s worth the effort.)
answered Aug 16 '17 at 14:09
Stephen KittStephen Kitt
167k24373452
I would just remove those lines of code; it’s not up to individual packages to force security upgrades in other packages.
If you look at the Debian package’s rules, you’ll see it doesn’t have anything like this. In any case, as you point out the dependencies can’t work on Debian 9 since that uses a different package name for OpenSSL.
(It should be possible to work out a disjunction which would enforce the right package upgrades, but I don’t think it’s worth the effort.)
answered Aug 16 '17 at 14:09
Stephen KittStephen Kitt
167k24373452
edited Jan 3 at 14:17
answered Aug 16 '17 at 14:09
Stephen KittStephen Kitt
167k24373452
answered Aug 16 '17 at 14:09
Stephen KittStephen Kitt
167k24373452
answered Aug 16 '17 at 14:09
Stephen KittStephen Kitt
167k24373452
167k24373452
It makes sense, going to propose a patch without those lines. Thanks.
– Rui F Ribeiro
Aug 16 '17 at 14:15
(Although those rules will prevent running FR in the recent Debian and derivates, the changes were not approved. I still understand their point of view, the bigger problem is Debian not having a maintainer for FR )
– Rui F Ribeiro
Aug 21 '17 at 10:56
You could join the maintenance team ;-).
– Stephen Kitt
Aug 21 '17 at 11:31
add a comment |
It makes sense, going to propose a patch without those lines. Thanks.
– Rui F Ribeiro
Aug 16 '17 at 14:15
(Although those rules will prevent running FR in the recent Debian and derivates, the changes were not approved. I still understand their point of view, the bigger problem is Debian not having a maintainer for FR )
– Rui F Ribeiro
Aug 21 '17 at 10:56
You could join the maintenance team ;-).
– Stephen Kitt
Aug 21 '17 at 11:31
It makes sense, going to propose a patch without those lines. Thanks.
– Rui F Ribeiro
Aug 16 '17 at 14:15
It makes sense, going to propose a patch without those lines. Thanks.
– Rui F Ribeiro
Aug 16 '17 at 14:15
(Although those rules will prevent running FR in the recent Debian and derivates, the changes were not approved. I still understand their point of view, the bigger problem is Debian not having a maintainer for FR )
– Rui F Ribeiro
Aug 21 '17 at 10:56
(Although those rules will prevent running FR in the recent Debian and derivates, the changes were not approved. I still understand their point of view, the bigger problem is Debian not having a maintainer for FR )
– Rui F Ribeiro
Aug 21 '17 at 10:56
You could join the maintenance team ;-).
– Stephen Kitt
Aug 21 '17 at 11:31
You could join the maintenance team ;-).
– Stephen Kitt
Aug 21 '17 at 11:31
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f386442%2fdefining-multiple-library-dependencies%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Is that piece of code something you added? If so, why do you want to enforce the Heartbleed fix in your FreeRADIUS package? (I can understand why you’d want to do this, but typically you’d enforce “being up-to-date” through other means; this is not something you’d expect in a package, which is why the packaging tools don’t provide for it very well.)
– Stephen Kitt
Aug 16 '17 at 14:00
@StephenKitt The code is verbatim as in the official git repo.
– Rui F Ribeiro
Aug 16 '17 at 14:02