Build the same source package for different Debian based distros
I wand to build multiple .deb packages from same source for different versions and distros.
Even if the source code is exactly same, some files in debian folder can not be shared because different dependency and distro name.
So, I want to make multiple 'debian' directories for each version/distro and specify where to search it when build package.
Is it possible?
For your information, I'm using debuild command to build .deb package.
compiling packaging deb
add a comment |
I wand to build multiple .deb packages from same source for different versions and distros.
Even if the source code is exactly same, some files in debian folder can not be shared because different dependency and distro name.
So, I want to make multiple 'debian' directories for each version/distro and specify where to search it when build package.
Is it possible?
For your information, I'm using debuild command to build .deb package.
compiling packaging deb
add a comment |
I wand to build multiple .deb packages from same source for different versions and distros.
Even if the source code is exactly same, some files in debian folder can not be shared because different dependency and distro name.
So, I want to make multiple 'debian' directories for each version/distro and specify where to search it when build package.
Is it possible?
For your information, I'm using debuild command to build .deb package.
compiling packaging deb
I wand to build multiple .deb packages from same source for different versions and distros.
Even if the source code is exactly same, some files in debian folder can not be shared because different dependency and distro name.
So, I want to make multiple 'debian' directories for each version/distro and specify where to search it when build package.
Is it possible?
For your information, I'm using debuild command to build .deb package.
compiling packaging deb
compiling packaging deb
edited Jan 15 '15 at 22:48
Gilles
531k12810631592
531k12810631592
asked Jan 15 '15 at 18:41
xylosperxylosper
1356
1356
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Using different branches is one approach, and I can suggest edits for @mestia’s answer if it seems appropriate (but read on...).
Another approach is to keep different files side-by-side; see Solaar for an example of this.
But both of these approaches have a significant shortcoming: they’re unsuitable for packages in Debian or Ubuntu (or probably other derivatives). If you intend on getting your package in a distribution some day, you should package it in such a way that the same set of files produces the correct result in the various distributions.
For an example of this, have a look at the Debian packaging for Solaar (full disclosure: I did the packaging).
The general idea is to ask dpkg-vendor
what the distribution is; so for Solaar, which has different dependencies in Debian and Ubuntu, debian/rules
has
derives_from_ubuntu := $(shell (dpkg-vendor --derives-from Ubuntu && echo "yes") || echo "no")
and further down an override for dh_gencontrol
to fill in “substvars” as appropriate:
override_dh_gencontrol:
ifeq ($(derives_from_ubuntu),yes)
dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme-full | oxygen-icon-theme-complete' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme-full
else
dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme | oxygen-icon-theme' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme
endif
This fills in the appropriate variables in debian/control
:
Package: solaar
Architecture: all
Depends: ${misc:Depends}, ${debconf:Depends}, udev (>= 175), passwd | adduser,
${python:Depends}, python-pyudev (>= 0.13), python-gi (>= 3.2), gir1.2-gtk-3.0 (>= 3.4),
${solaar:Desktop-Icon-Theme}
and
Package: solaar-gnome3
Architecture: all
Section: gnome
Depends: ${misc:Depends}, solaar (= ${source:Version}),
gir1.2-appindicator3-0.1, gnome-shell (>= 3.4) | unity (>= 5.10),
${solaar:Gnome-Icon-Theme}
You can use the test in debian/rules
to control any action you can do in a makefile, which means you can combine this with alternative files and, for example, link the appropriate files just before they’re used in the package build.
add a comment |
Probably you can go with git-buildpackage
and keep the different debian directories in different branches.
3
I'd suggest adding an example of how to do this, or at least a few links to where you can find more instructions on using git-buildpacakge.
– derobert
Jan 15 '15 at 21:39
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%2f179318%2fbuild-the-same-source-package-for-different-debian-based-distros%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Using different branches is one approach, and I can suggest edits for @mestia’s answer if it seems appropriate (but read on...).
Another approach is to keep different files side-by-side; see Solaar for an example of this.
But both of these approaches have a significant shortcoming: they’re unsuitable for packages in Debian or Ubuntu (or probably other derivatives). If you intend on getting your package in a distribution some day, you should package it in such a way that the same set of files produces the correct result in the various distributions.
For an example of this, have a look at the Debian packaging for Solaar (full disclosure: I did the packaging).
The general idea is to ask dpkg-vendor
what the distribution is; so for Solaar, which has different dependencies in Debian and Ubuntu, debian/rules
has
derives_from_ubuntu := $(shell (dpkg-vendor --derives-from Ubuntu && echo "yes") || echo "no")
and further down an override for dh_gencontrol
to fill in “substvars” as appropriate:
override_dh_gencontrol:
ifeq ($(derives_from_ubuntu),yes)
dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme-full | oxygen-icon-theme-complete' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme-full
else
dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme | oxygen-icon-theme' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme
endif
This fills in the appropriate variables in debian/control
:
Package: solaar
Architecture: all
Depends: ${misc:Depends}, ${debconf:Depends}, udev (>= 175), passwd | adduser,
${python:Depends}, python-pyudev (>= 0.13), python-gi (>= 3.2), gir1.2-gtk-3.0 (>= 3.4),
${solaar:Desktop-Icon-Theme}
and
Package: solaar-gnome3
Architecture: all
Section: gnome
Depends: ${misc:Depends}, solaar (= ${source:Version}),
gir1.2-appindicator3-0.1, gnome-shell (>= 3.4) | unity (>= 5.10),
${solaar:Gnome-Icon-Theme}
You can use the test in debian/rules
to control any action you can do in a makefile, which means you can combine this with alternative files and, for example, link the appropriate files just before they’re used in the package build.
add a comment |
Using different branches is one approach, and I can suggest edits for @mestia’s answer if it seems appropriate (but read on...).
Another approach is to keep different files side-by-side; see Solaar for an example of this.
But both of these approaches have a significant shortcoming: they’re unsuitable for packages in Debian or Ubuntu (or probably other derivatives). If you intend on getting your package in a distribution some day, you should package it in such a way that the same set of files produces the correct result in the various distributions.
For an example of this, have a look at the Debian packaging for Solaar (full disclosure: I did the packaging).
The general idea is to ask dpkg-vendor
what the distribution is; so for Solaar, which has different dependencies in Debian and Ubuntu, debian/rules
has
derives_from_ubuntu := $(shell (dpkg-vendor --derives-from Ubuntu && echo "yes") || echo "no")
and further down an override for dh_gencontrol
to fill in “substvars” as appropriate:
override_dh_gencontrol:
ifeq ($(derives_from_ubuntu),yes)
dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme-full | oxygen-icon-theme-complete' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme-full
else
dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme | oxygen-icon-theme' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme
endif
This fills in the appropriate variables in debian/control
:
Package: solaar
Architecture: all
Depends: ${misc:Depends}, ${debconf:Depends}, udev (>= 175), passwd | adduser,
${python:Depends}, python-pyudev (>= 0.13), python-gi (>= 3.2), gir1.2-gtk-3.0 (>= 3.4),
${solaar:Desktop-Icon-Theme}
and
Package: solaar-gnome3
Architecture: all
Section: gnome
Depends: ${misc:Depends}, solaar (= ${source:Version}),
gir1.2-appindicator3-0.1, gnome-shell (>= 3.4) | unity (>= 5.10),
${solaar:Gnome-Icon-Theme}
You can use the test in debian/rules
to control any action you can do in a makefile, which means you can combine this with alternative files and, for example, link the appropriate files just before they’re used in the package build.
add a comment |
Using different branches is one approach, and I can suggest edits for @mestia’s answer if it seems appropriate (but read on...).
Another approach is to keep different files side-by-side; see Solaar for an example of this.
But both of these approaches have a significant shortcoming: they’re unsuitable for packages in Debian or Ubuntu (or probably other derivatives). If you intend on getting your package in a distribution some day, you should package it in such a way that the same set of files produces the correct result in the various distributions.
For an example of this, have a look at the Debian packaging for Solaar (full disclosure: I did the packaging).
The general idea is to ask dpkg-vendor
what the distribution is; so for Solaar, which has different dependencies in Debian and Ubuntu, debian/rules
has
derives_from_ubuntu := $(shell (dpkg-vendor --derives-from Ubuntu && echo "yes") || echo "no")
and further down an override for dh_gencontrol
to fill in “substvars” as appropriate:
override_dh_gencontrol:
ifeq ($(derives_from_ubuntu),yes)
dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme-full | oxygen-icon-theme-complete' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme-full
else
dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme | oxygen-icon-theme' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme
endif
This fills in the appropriate variables in debian/control
:
Package: solaar
Architecture: all
Depends: ${misc:Depends}, ${debconf:Depends}, udev (>= 175), passwd | adduser,
${python:Depends}, python-pyudev (>= 0.13), python-gi (>= 3.2), gir1.2-gtk-3.0 (>= 3.4),
${solaar:Desktop-Icon-Theme}
and
Package: solaar-gnome3
Architecture: all
Section: gnome
Depends: ${misc:Depends}, solaar (= ${source:Version}),
gir1.2-appindicator3-0.1, gnome-shell (>= 3.4) | unity (>= 5.10),
${solaar:Gnome-Icon-Theme}
You can use the test in debian/rules
to control any action you can do in a makefile, which means you can combine this with alternative files and, for example, link the appropriate files just before they’re used in the package build.
Using different branches is one approach, and I can suggest edits for @mestia’s answer if it seems appropriate (but read on...).
Another approach is to keep different files side-by-side; see Solaar for an example of this.
But both of these approaches have a significant shortcoming: they’re unsuitable for packages in Debian or Ubuntu (or probably other derivatives). If you intend on getting your package in a distribution some day, you should package it in such a way that the same set of files produces the correct result in the various distributions.
For an example of this, have a look at the Debian packaging for Solaar (full disclosure: I did the packaging).
The general idea is to ask dpkg-vendor
what the distribution is; so for Solaar, which has different dependencies in Debian and Ubuntu, debian/rules
has
derives_from_ubuntu := $(shell (dpkg-vendor --derives-from Ubuntu && echo "yes") || echo "no")
and further down an override for dh_gencontrol
to fill in “substvars” as appropriate:
override_dh_gencontrol:
ifeq ($(derives_from_ubuntu),yes)
dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme-full | oxygen-icon-theme-complete' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme-full
else
dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme | oxygen-icon-theme' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme
endif
This fills in the appropriate variables in debian/control
:
Package: solaar
Architecture: all
Depends: ${misc:Depends}, ${debconf:Depends}, udev (>= 175), passwd | adduser,
${python:Depends}, python-pyudev (>= 0.13), python-gi (>= 3.2), gir1.2-gtk-3.0 (>= 3.4),
${solaar:Desktop-Icon-Theme}
and
Package: solaar-gnome3
Architecture: all
Section: gnome
Depends: ${misc:Depends}, solaar (= ${source:Version}),
gir1.2-appindicator3-0.1, gnome-shell (>= 3.4) | unity (>= 5.10),
${solaar:Gnome-Icon-Theme}
You can use the test in debian/rules
to control any action you can do in a makefile, which means you can combine this with alternative files and, for example, link the appropriate files just before they’re used in the package build.
edited 2 hours ago
answered Jan 29 '15 at 19:57
Stephen KittStephen Kitt
167k24372452
167k24372452
add a comment |
add a comment |
Probably you can go with git-buildpackage
and keep the different debian directories in different branches.
3
I'd suggest adding an example of how to do this, or at least a few links to where you can find more instructions on using git-buildpacakge.
– derobert
Jan 15 '15 at 21:39
add a comment |
Probably you can go with git-buildpackage
and keep the different debian directories in different branches.
3
I'd suggest adding an example of how to do this, or at least a few links to where you can find more instructions on using git-buildpacakge.
– derobert
Jan 15 '15 at 21:39
add a comment |
Probably you can go with git-buildpackage
and keep the different debian directories in different branches.
Probably you can go with git-buildpackage
and keep the different debian directories in different branches.
edited Jan 15 '15 at 21:41
Ramesh
23.3k32101182
23.3k32101182
answered Jan 15 '15 at 20:37
mestiamestia
785
785
3
I'd suggest adding an example of how to do this, or at least a few links to where you can find more instructions on using git-buildpacakge.
– derobert
Jan 15 '15 at 21:39
add a comment |
3
I'd suggest adding an example of how to do this, or at least a few links to where you can find more instructions on using git-buildpacakge.
– derobert
Jan 15 '15 at 21:39
3
3
I'd suggest adding an example of how to do this, or at least a few links to where you can find more instructions on using git-buildpacakge.
– derobert
Jan 15 '15 at 21:39
I'd suggest adding an example of how to do this, or at least a few links to where you can find more instructions on using git-buildpacakge.
– derobert
Jan 15 '15 at 21:39
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%2f179318%2fbuild-the-same-source-package-for-different-debian-based-distros%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