Two differently-versioned binary Debian packages from one source
I'm thinking about properly Debianizing a package, which contains two parts in one upstream tarball/git branch:
- Userspace binaries and libraries, version 1.5.0 (
foobardbinary package) - Kernel module, version 0.8.5 (
foobar-dkms)
The problem is that versions differ. Is there any sane and correct way to build two differently-versioned binary packages from one source package in such case?
If possible, I'd like something cleaner than creating two source packages, or versioning both packages as 1.5.0 (even though the module has proper MODULE_VERSION specified in source).
debian packaging
asked Feb 11 '12 at 13:50
drdaeman
25818
migrated from serverfault.com Feb 13 '12 at 20:21
This question came from our site for system and network administrators.
add a comment |
I'm thinking about properly Debianizing a package, which contains two parts in one upstream tarball/git branch:
- Userspace binaries and libraries, version 1.5.0 (
foobardbinary package) - Kernel module, version 0.8.5 (
foobar-dkms)
The problem is that versions differ. Is there any sane and correct way to build two differently-versioned binary packages from one source package in such case?
If possible, I'd like something cleaner than creating two source packages, or versioning both packages as 1.5.0 (even though the module has proper MODULE_VERSION specified in source).
debian packaging
asked Feb 11 '12 at 13:50
drdaeman
25818
migrated from serverfault.com Feb 13 '12 at 20:21
This question came from our site for system and network administrators.
add a comment |
I'm thinking about properly Debianizing a package, which contains two parts in one upstream tarball/git branch:
- Userspace binaries and libraries, version 1.5.0 (
foobardbinary package) - Kernel module, version 0.8.5 (
foobar-dkms)
The problem is that versions differ. Is there any sane and correct way to build two differently-versioned binary packages from one source package in such case?
If possible, I'd like something cleaner than creating two source packages, or versioning both packages as 1.5.0 (even though the module has proper MODULE_VERSION specified in source).
debian packaging
asked Feb 11 '12 at 13:50
drdaeman
25818
I'm thinking about properly Debianizing a package, which contains two parts in one upstream tarball/git branch:
- Userspace binaries and libraries, version 1.5.0 (
foobardbinary package) - Kernel module, version 0.8.5 (
foobar-dkms)
The problem is that versions differ. Is there any sane and correct way to build two differently-versioned binary packages from one source package in such case?
If possible, I'd like something cleaner than creating two source packages, or versioning both packages as 1.5.0 (even though the module has proper MODULE_VERSION specified in source).
debian packaging
debian packaging
asked Feb 11 '12 at 13:50
drdaeman
25818
asked Feb 11 '12 at 13:50
drdaeman
25818
asked Feb 11 '12 at 13:50
drdaeman
25818
asked Feb 11 '12 at 13:50
drdaeman
25818
asked Feb 11 '12 at 13:50
drdaeman
25818
25818
migrated from serverfault.com Feb 13 '12 at 20:21
This question came from our site for system and network administrators.
migrated from serverfault.com Feb 13 '12 at 20:21
This question came from our site for system and network administrators.
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
The version of a binary package in Debian is determined by dpkg-gencontrol, which generates the final control file which ends up in the binary package. The -v option specifies the version number; by default the version number is taken from debian/changelog, but that can be overridden.
There are a few examples of this in the archive; see for example my own gcc-mingw-w64 package, which has its own (source) version number, but generates binary packages whose versions merge the underlying gcc-source (currently, gcc-7-source) version number and the source package's number. Thus in Debian 9, gcc-mingw-w64version 19.3 produces binary packages versioned 6.3.0-18+19.3.
To build different binary packages with different versions from a single source, you'd combine the -v option with the -p option (which specifies the package to process), and run dpkg-gencontrol (or one of its wrappers, such as dh_gencontrol) as many times as necessary.
There is at least package in the archive which demonstrates this: android-sdk-meta builds binary packages with two different versions, android-sdk which takes the source version, and four other packages whose binary version is specified in debian/rules.
The Debian Policy chapter on control fields has more detail on the differences between source and binary control files.
answered May 14 '16 at 19:47
Stephen Kitt
163k24362441
The example you gave for a package is just too complex. Perhaps a more simple source package example would help.
– Khurshid Alam
Mar 6 '17 at 13:23
Ah. Right. Second example is fine. And it's working. Thanks.
– Khurshid Alam
Mar 6 '17 at 15:32
add a comment |
In Debian and Ubuntu packages, the version is specified in the debian/changelog file, and it is designed so that all packages generated by a source package have the exact same version.
answered Feb 22 '12 at 10:13
ℝaphink
25118
add a comment |
You can check pidgin example. It generates libpurple0, pidgin, pidgin-data, pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple-dev, libpurple-bin packages from one single source.
Get the source from:
http://packages.debian.org/squeeze/pidgin
[pidgin_2.7.3-1+squeeze2.dsc]
[pidgin_2.7.3.orig.tar.bz2]
[pidgin_2.7.3-1+squeeze2.debian.tar.gz]
The file that control the build is debian/rules. More info at:
http://www.debian.org/doc/debian-policy/ch-source.html
http://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.html
answered Feb 13 '12 at 1:43
Peter Senna
1011
It seems that pidgin, pidgin-data, finch and libpurple0 binary packages are all of the same version, for example2.7.3-1+squeeze2. I know, I can create multi-binary source packages (in fact, I already did it), but only like this — where all generated packages are of same version.
– drdaeman
Feb 13 '12 at 6:05
2
You are right! :-( The version comes from changelog file. I will do some testing this week, the first test will have one 'debian' directory for each resulting binary. Same source for all binaries but different 'debian' directory for each one. I'll post the results here.
– Peter Senna
Feb 13 '12 at 14:41
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%2f31584%2ftwo-differently-versioned-binary-debian-packages-from-one-source%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
The version of a binary package in Debian is determined by dpkg-gencontrol, which generates the final control file which ends up in the binary package. The -v option specifies the version number; by default the version number is taken from debian/changelog, but that can be overridden.
There are a few examples of this in the archive; see for example my own gcc-mingw-w64 package, which has its own (source) version number, but generates binary packages whose versions merge the underlying gcc-source (currently, gcc-7-source) version number and the source package's number. Thus in Debian 9, gcc-mingw-w64version 19.3 produces binary packages versioned 6.3.0-18+19.3.
To build different binary packages with different versions from a single source, you'd combine the -v option with the -p option (which specifies the package to process), and run dpkg-gencontrol (or one of its wrappers, such as dh_gencontrol) as many times as necessary.
There is at least package in the archive which demonstrates this: android-sdk-meta builds binary packages with two different versions, android-sdk which takes the source version, and four other packages whose binary version is specified in debian/rules.
The Debian Policy chapter on control fields has more detail on the differences between source and binary control files.
answered May 14 '16 at 19:47
Stephen Kitt
163k24362441
The example you gave for a package is just too complex. Perhaps a more simple source package example would help.
– Khurshid Alam
Mar 6 '17 at 13:23
Ah. Right. Second example is fine. And it's working. Thanks.
– Khurshid Alam
Mar 6 '17 at 15:32
add a comment |
The version of a binary package in Debian is determined by dpkg-gencontrol, which generates the final control file which ends up in the binary package. The -v option specifies the version number; by default the version number is taken from debian/changelog, but that can be overridden.
There are a few examples of this in the archive; see for example my own gcc-mingw-w64 package, which has its own (source) version number, but generates binary packages whose versions merge the underlying gcc-source (currently, gcc-7-source) version number and the source package's number. Thus in Debian 9, gcc-mingw-w64version 19.3 produces binary packages versioned 6.3.0-18+19.3.
To build different binary packages with different versions from a single source, you'd combine the -v option with the -p option (which specifies the package to process), and run dpkg-gencontrol (or one of its wrappers, such as dh_gencontrol) as many times as necessary.
There is at least package in the archive which demonstrates this: android-sdk-meta builds binary packages with two different versions, android-sdk which takes the source version, and four other packages whose binary version is specified in debian/rules.
The Debian Policy chapter on control fields has more detail on the differences between source and binary control files.
answered May 14 '16 at 19:47
Stephen Kitt
163k24362441
The example you gave for a package is just too complex. Perhaps a more simple source package example would help.
– Khurshid Alam
Mar 6 '17 at 13:23
Ah. Right. Second example is fine. And it's working. Thanks.
– Khurshid Alam
Mar 6 '17 at 15:32
add a comment |
The version of a binary package in Debian is determined by dpkg-gencontrol, which generates the final control file which ends up in the binary package. The -v option specifies the version number; by default the version number is taken from debian/changelog, but that can be overridden.
There are a few examples of this in the archive; see for example my own gcc-mingw-w64 package, which has its own (source) version number, but generates binary packages whose versions merge the underlying gcc-source (currently, gcc-7-source) version number and the source package's number. Thus in Debian 9, gcc-mingw-w64version 19.3 produces binary packages versioned 6.3.0-18+19.3.
To build different binary packages with different versions from a single source, you'd combine the -v option with the -p option (which specifies the package to process), and run dpkg-gencontrol (or one of its wrappers, such as dh_gencontrol) as many times as necessary.
There is at least package in the archive which demonstrates this: android-sdk-meta builds binary packages with two different versions, android-sdk which takes the source version, and four other packages whose binary version is specified in debian/rules.
The Debian Policy chapter on control fields has more detail on the differences between source and binary control files.
answered May 14 '16 at 19:47
Stephen Kitt
163k24362441
The version of a binary package in Debian is determined by dpkg-gencontrol, which generates the final control file which ends up in the binary package. The -v option specifies the version number; by default the version number is taken from debian/changelog, but that can be overridden.
There are a few examples of this in the archive; see for example my own gcc-mingw-w64 package, which has its own (source) version number, but generates binary packages whose versions merge the underlying gcc-source (currently, gcc-7-source) version number and the source package's number. Thus in Debian 9, gcc-mingw-w64version 19.3 produces binary packages versioned 6.3.0-18+19.3.
To build different binary packages with different versions from a single source, you'd combine the -v option with the -p option (which specifies the package to process), and run dpkg-gencontrol (or one of its wrappers, such as dh_gencontrol) as many times as necessary.
There is at least package in the archive which demonstrates this: android-sdk-meta builds binary packages with two different versions, android-sdk which takes the source version, and four other packages whose binary version is specified in debian/rules.
The Debian Policy chapter on control fields has more detail on the differences between source and binary control files.
answered May 14 '16 at 19:47
Stephen Kitt
163k24362441
edited 10 hours ago
answered May 14 '16 at 19:47
Stephen Kitt
163k24362441
answered May 14 '16 at 19:47
Stephen Kitt
163k24362441
answered May 14 '16 at 19:47
Stephen Kitt
163k24362441
163k24362441
The example you gave for a package is just too complex. Perhaps a more simple source package example would help.
– Khurshid Alam
Mar 6 '17 at 13:23
Ah. Right. Second example is fine. And it's working. Thanks.
– Khurshid Alam
Mar 6 '17 at 15:32
add a comment |
The example you gave for a package is just too complex. Perhaps a more simple source package example would help.
– Khurshid Alam
Mar 6 '17 at 13:23
Ah. Right. Second example is fine. And it's working. Thanks.
– Khurshid Alam
Mar 6 '17 at 15:32
The example you gave for a package is just too complex. Perhaps a more simple source package example would help.
– Khurshid Alam
Mar 6 '17 at 13:23
The example you gave for a package is just too complex. Perhaps a more simple source package example would help.
– Khurshid Alam
Mar 6 '17 at 13:23
Ah. Right. Second example is fine. And it's working. Thanks.
– Khurshid Alam
Mar 6 '17 at 15:32
Ah. Right. Second example is fine. And it's working. Thanks.
– Khurshid Alam
Mar 6 '17 at 15:32
add a comment |
In Debian and Ubuntu packages, the version is specified in the debian/changelog file, and it is designed so that all packages generated by a source package have the exact same version.
answered Feb 22 '12 at 10:13
ℝaphink
25118
add a comment |
In Debian and Ubuntu packages, the version is specified in the debian/changelog file, and it is designed so that all packages generated by a source package have the exact same version.
answered Feb 22 '12 at 10:13
ℝaphink
25118
add a comment |
In Debian and Ubuntu packages, the version is specified in the debian/changelog file, and it is designed so that all packages generated by a source package have the exact same version.
answered Feb 22 '12 at 10:13
ℝaphink
25118
In Debian and Ubuntu packages, the version is specified in the debian/changelog file, and it is designed so that all packages generated by a source package have the exact same version.
answered Feb 22 '12 at 10:13
ℝaphink
25118
answered Feb 22 '12 at 10:13
ℝaphink
25118
answered Feb 22 '12 at 10:13
ℝaphink
25118
answered Feb 22 '12 at 10:13
ℝaphink
25118
25118
add a comment |
add a comment |
You can check pidgin example. It generates libpurple0, pidgin, pidgin-data, pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple-dev, libpurple-bin packages from one single source.
Get the source from:
http://packages.debian.org/squeeze/pidgin
[pidgin_2.7.3-1+squeeze2.dsc]
[pidgin_2.7.3.orig.tar.bz2]
[pidgin_2.7.3-1+squeeze2.debian.tar.gz]
The file that control the build is debian/rules. More info at:
http://www.debian.org/doc/debian-policy/ch-source.html
http://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.html
answered Feb 13 '12 at 1:43
Peter Senna
1011
It seems that pidgin, pidgin-data, finch and libpurple0 binary packages are all of the same version, for example2.7.3-1+squeeze2. I know, I can create multi-binary source packages (in fact, I already did it), but only like this — where all generated packages are of same version.
– drdaeman
Feb 13 '12 at 6:05
2
You are right! :-( The version comes from changelog file. I will do some testing this week, the first test will have one 'debian' directory for each resulting binary. Same source for all binaries but different 'debian' directory for each one. I'll post the results here.
– Peter Senna
Feb 13 '12 at 14:41
add a comment |
You can check pidgin example. It generates libpurple0, pidgin, pidgin-data, pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple-dev, libpurple-bin packages from one single source.
Get the source from:
http://packages.debian.org/squeeze/pidgin
[pidgin_2.7.3-1+squeeze2.dsc]
[pidgin_2.7.3.orig.tar.bz2]
[pidgin_2.7.3-1+squeeze2.debian.tar.gz]
The file that control the build is debian/rules. More info at:
http://www.debian.org/doc/debian-policy/ch-source.html
http://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.html
answered Feb 13 '12 at 1:43
Peter Senna
1011
It seems that pidgin, pidgin-data, finch and libpurple0 binary packages are all of the same version, for example2.7.3-1+squeeze2. I know, I can create multi-binary source packages (in fact, I already did it), but only like this — where all generated packages are of same version.
– drdaeman
Feb 13 '12 at 6:05
2
You are right! :-( The version comes from changelog file. I will do some testing this week, the first test will have one 'debian' directory for each resulting binary. Same source for all binaries but different 'debian' directory for each one. I'll post the results here.
– Peter Senna
Feb 13 '12 at 14:41
add a comment |
You can check pidgin example. It generates libpurple0, pidgin, pidgin-data, pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple-dev, libpurple-bin packages from one single source.
Get the source from:
http://packages.debian.org/squeeze/pidgin
[pidgin_2.7.3-1+squeeze2.dsc]
[pidgin_2.7.3.orig.tar.bz2]
[pidgin_2.7.3-1+squeeze2.debian.tar.gz]
The file that control the build is debian/rules. More info at:
http://www.debian.org/doc/debian-policy/ch-source.html
http://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.html
answered Feb 13 '12 at 1:43
Peter Senna
1011
You can check pidgin example. It generates libpurple0, pidgin, pidgin-data, pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple-dev, libpurple-bin packages from one single source.
Get the source from:
http://packages.debian.org/squeeze/pidgin
[pidgin_2.7.3-1+squeeze2.dsc]
[pidgin_2.7.3.orig.tar.bz2]
[pidgin_2.7.3-1+squeeze2.debian.tar.gz]
The file that control the build is debian/rules. More info at:
http://www.debian.org/doc/debian-policy/ch-source.html
http://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.html
answered Feb 13 '12 at 1:43
Peter Senna
1011
answered Feb 13 '12 at 1:43
Peter Senna
1011
answered Feb 13 '12 at 1:43
Peter Senna
1011
answered Feb 13 '12 at 1:43
Peter Senna
1011
1011
It seems that pidgin, pidgin-data, finch and libpurple0 binary packages are all of the same version, for example2.7.3-1+squeeze2. I know, I can create multi-binary source packages (in fact, I already did it), but only like this — where all generated packages are of same version.
– drdaeman
Feb 13 '12 at 6:05
2
You are right! :-( The version comes from changelog file. I will do some testing this week, the first test will have one 'debian' directory for each resulting binary. Same source for all binaries but different 'debian' directory for each one. I'll post the results here.
– Peter Senna
Feb 13 '12 at 14:41
add a comment |
It seems that pidgin, pidgin-data, finch and libpurple0 binary packages are all of the same version, for example2.7.3-1+squeeze2. I know, I can create multi-binary source packages (in fact, I already did it), but only like this — where all generated packages are of same version.
– drdaeman
Feb 13 '12 at 6:05
2
You are right! :-( The version comes from changelog file. I will do some testing this week, the first test will have one 'debian' directory for each resulting binary. Same source for all binaries but different 'debian' directory for each one. I'll post the results here.
– Peter Senna
Feb 13 '12 at 14:41
It seems that pidgin, pidgin-data, finch and libpurple0 binary packages are all of the same version, for example
2.7.3-1+squeeze2. I know, I can create multi-binary source packages (in fact, I already did it), but only like this — where all generated packages are of same version.– drdaeman
Feb 13 '12 at 6:05
It seems that pidgin, pidgin-data, finch and libpurple0 binary packages are all of the same version, for example
2.7.3-1+squeeze2. I know, I can create multi-binary source packages (in fact, I already did it), but only like this — where all generated packages are of same version.– drdaeman
Feb 13 '12 at 6:05
2
2
You are right! :-( The version comes from changelog file. I will do some testing this week, the first test will have one 'debian' directory for each resulting binary. Same source for all binaries but different 'debian' directory for each one. I'll post the results here.
– Peter Senna
Feb 13 '12 at 14:41
You are right! :-( The version comes from changelog file. I will do some testing this week, the first test will have one 'debian' directory for each resulting binary. Same source for all binaries but different 'debian' directory for each one. I'll post the results here.
– Peter Senna
Feb 13 '12 at 14:41
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f31584%2ftwo-differently-versioned-binary-debian-packages-from-one-source%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
