What is the accepted way to maintain a patched version of a package for unprivileged installation?
I use some common software packages frequently enough that I found it worthwhile to modify their code a bit to work more smoothly for my peculiar needs. However, I was not able to get my changes accepted upstream.
I need to install them on my various user accounts. Some of these accounts are on shared systems where I either don't have root access, or where I don't want to force other users to use my version of a piece of software.
To make things organized and transparent, I'd like to keep my changes separate from the released (upstream) version of each package. I know this is done all the time with standard packaging tools, and there are tools like Quilt which can help me keep a series of patches up to date with a released package, and more advanced options like Guilt and "Mercurial queues" which I haven't really looked into.
However, most distro packaging tools don't support installing a package into a user's home directory - my stuff goes in ~/.local/bin for example - so I'm looking at combining something like Quilt to apply my patches, with some custom install scripts to do the upstream downloading and local installation. I guess these would all be part of a Git repo, and then I'd have an additional script to download all my patched packages from GitHub, and build and install them in my home directory.
All in all I think it's not too complicated, but before I start I wanted to see what others have done or agreed upon.
A related question, What is the recommended way to maintain local patches to debian packages? is asking about distribution-specific packages with global (privileged) installation. Also relevant, but more general, is How to manage open source project patches which can't push to upstream?.
package-management git version-control quilt
asked 1 hour ago
MetamorphicMetamorphic
354110
add a comment |
I use some common software packages frequently enough that I found it worthwhile to modify their code a bit to work more smoothly for my peculiar needs. However, I was not able to get my changes accepted upstream.
I need to install them on my various user accounts. Some of these accounts are on shared systems where I either don't have root access, or where I don't want to force other users to use my version of a piece of software.
To make things organized and transparent, I'd like to keep my changes separate from the released (upstream) version of each package. I know this is done all the time with standard packaging tools, and there are tools like Quilt which can help me keep a series of patches up to date with a released package, and more advanced options like Guilt and "Mercurial queues" which I haven't really looked into.
However, most distro packaging tools don't support installing a package into a user's home directory - my stuff goes in ~/.local/bin for example - so I'm looking at combining something like Quilt to apply my patches, with some custom install scripts to do the upstream downloading and local installation. I guess these would all be part of a Git repo, and then I'd have an additional script to download all my patched packages from GitHub, and build and install them in my home directory.
All in all I think it's not too complicated, but before I start I wanted to see what others have done or agreed upon.
A related question, What is the recommended way to maintain local patches to debian packages? is asking about distribution-specific packages with global (privileged) installation. Also relevant, but more general, is How to manage open source project patches which can't push to upstream?.
package-management git version-control quilt
asked 1 hour ago
MetamorphicMetamorphic
354110
There's a 101 different ways of doing this, and the best way is going to be unique to your environment. As a result, I think this is gonna be a "primarily opinion based" type question.
– Stephen Harris
42 mins ago
@StephenHarris: I tried to restrict it a little by asking "what others have done or agreed upon", although as the two similar questions I linked were not labeled "opinion-based", I had not anticipated that my question would be closed for that reason.
– Metamorphic
38 mins ago
add a comment |
I use some common software packages frequently enough that I found it worthwhile to modify their code a bit to work more smoothly for my peculiar needs. However, I was not able to get my changes accepted upstream.
I need to install them on my various user accounts. Some of these accounts are on shared systems where I either don't have root access, or where I don't want to force other users to use my version of a piece of software.
To make things organized and transparent, I'd like to keep my changes separate from the released (upstream) version of each package. I know this is done all the time with standard packaging tools, and there are tools like Quilt which can help me keep a series of patches up to date with a released package, and more advanced options like Guilt and "Mercurial queues" which I haven't really looked into.
However, most distro packaging tools don't support installing a package into a user's home directory - my stuff goes in ~/.local/bin for example - so I'm looking at combining something like Quilt to apply my patches, with some custom install scripts to do the upstream downloading and local installation. I guess these would all be part of a Git repo, and then I'd have an additional script to download all my patched packages from GitHub, and build and install them in my home directory.
All in all I think it's not too complicated, but before I start I wanted to see what others have done or agreed upon.
A related question, What is the recommended way to maintain local patches to debian packages? is asking about distribution-specific packages with global (privileged) installation. Also relevant, but more general, is How to manage open source project patches which can't push to upstream?.
package-management git version-control quilt
asked 1 hour ago
MetamorphicMetamorphic
354110
I use some common software packages frequently enough that I found it worthwhile to modify their code a bit to work more smoothly for my peculiar needs. However, I was not able to get my changes accepted upstream.
I need to install them on my various user accounts. Some of these accounts are on shared systems where I either don't have root access, or where I don't want to force other users to use my version of a piece of software.
To make things organized and transparent, I'd like to keep my changes separate from the released (upstream) version of each package. I know this is done all the time with standard packaging tools, and there are tools like Quilt which can help me keep a series of patches up to date with a released package, and more advanced options like Guilt and "Mercurial queues" which I haven't really looked into.
However, most distro packaging tools don't support installing a package into a user's home directory - my stuff goes in ~/.local/bin for example - so I'm looking at combining something like Quilt to apply my patches, with some custom install scripts to do the upstream downloading and local installation. I guess these would all be part of a Git repo, and then I'd have an additional script to download all my patched packages from GitHub, and build and install them in my home directory.
All in all I think it's not too complicated, but before I start I wanted to see what others have done or agreed upon.
A related question, What is the recommended way to maintain local patches to debian packages? is asking about distribution-specific packages with global (privileged) installation. Also relevant, but more general, is How to manage open source project patches which can't push to upstream?.
package-management git version-control quilt
package-management git version-control quilt
asked 1 hour ago
MetamorphicMetamorphic
354110
asked 1 hour ago
MetamorphicMetamorphic
354110
asked 1 hour ago
MetamorphicMetamorphic
354110
asked 1 hour ago
MetamorphicMetamorphic
354110
asked 1 hour ago
MetamorphicMetamorphic
354110
354110
There's a 101 different ways of doing this, and the best way is going to be unique to your environment. As a result, I think this is gonna be a "primarily opinion based" type question.
– Stephen Harris
42 mins ago
@StephenHarris: I tried to restrict it a little by asking "what others have done or agreed upon", although as the two similar questions I linked were not labeled "opinion-based", I had not anticipated that my question would be closed for that reason.
– Metamorphic
38 mins ago
add a comment |
There's a 101 different ways of doing this, and the best way is going to be unique to your environment. As a result, I think this is gonna be a "primarily opinion based" type question.
– Stephen Harris
42 mins ago
@StephenHarris: I tried to restrict it a little by asking "what others have done or agreed upon", although as the two similar questions I linked were not labeled "opinion-based", I had not anticipated that my question would be closed for that reason.
– Metamorphic
38 mins ago
There's a 101 different ways of doing this, and the best way is going to be unique to your environment. As a result, I think this is gonna be a "primarily opinion based" type question.
– Stephen Harris
42 mins ago
There's a 101 different ways of doing this, and the best way is going to be unique to your environment. As a result, I think this is gonna be a "primarily opinion based" type question.
– Stephen Harris
42 mins ago
@StephenHarris: I tried to restrict it a little by asking "what others have done or agreed upon", although as the two similar questions I linked were not labeled "opinion-based", I had not anticipated that my question would be closed for that reason.
– Metamorphic
38 mins ago
@StephenHarris: I tried to restrict it a little by asking "what others have done or agreed upon", although as the two similar questions I linked were not labeled "opinion-based", I had not anticipated that my question would be closed for that reason.
– Metamorphic
38 mins ago
add a comment |
0
active
oldest
votes
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%2f507078%2fwhat-is-the-accepted-way-to-maintain-a-patched-version-of-a-package-for-unprivil%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
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%2f507078%2fwhat-is-the-accepted-way-to-maintain-a-patched-version-of-a-package-for-unprivil%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
There's a 101 different ways of doing this, and the best way is going to be unique to your environment. As a result, I think this is gonna be a "primarily opinion based" type question.
– Stephen Harris
42 mins ago
@StephenHarris: I tried to restrict it a little by asking "what others have done or agreed upon", although as the two similar questions I linked were not labeled "opinion-based", I had not anticipated that my question would be closed for that reason.
– Metamorphic
38 mins ago