Hello everyone.
I wrote dh_splitpackage, a helper script that unambiguously splits the files of a binary package into multiple packages based on a configuration file.
The configuration file may point the primary package (the one that gets leftover files by default) as well as any number of additional packages with any number of inclusion and exclusion patterns.
The new script can be called instead of dh_install (assuming all the files you are interested in are already in debian/tmp/) or afterwards.
The biggest advantage compared to existing tools is clear and not-that-error-prone classification of files to packages. Any file that would be classified to more than one package (hitting patterns in both files) is clearly reported and prevents the package from building properly. In addition running the script displays each file from debian/tmp and the package it was classified to.
Using this script could greatly simplify many packages that currently rely on numerous *.install files and custom dh_install overrides in debian/rules.
You can find the code at lp:~zkrynicki/+junk/dh_splitpackage (tag: release-0.1) The source tree also includes debian packaging that makes use of the new script.
Best regards Zygmunt Krynicki
On Thu, Jun 2, 2011 at 6:16 PM, Zygmunt Krynicki zygmunt.krynicki@canonical.com wrote:
Hello everyone.
I wrote dh_splitpackage, a helper script that unambiguously splits the files of a binary package into multiple packages based on a configuration file.
The configuration file may point the primary package (the one that gets leftover files by default) as well as any number of additional packages with any number of inclusion and exclusion patterns.
The new script can be called instead of dh_install (assuming all the files you are interested in are already in debian/tmp/) or afterwards.
The biggest advantage compared to existing tools is clear and not-that-error-prone classification of files to packages. Any file that would be classified to more than one package (hitting patterns in both files) is clearly reported and prevents the package from building properly. In addition running the script displays each file from debian/tmp and the package it was classified to.
Using this script could greatly simplify many packages that currently rely on numerous *.install files and custom dh_install overrides in debian/rules.
You can find the code at lp:~zkrynicki/+junk/dh_splitpackage (tag: release-0.1) The source tree also includes debian packaging that makes use of the new script.
Ubuntu has gotten quite a bit of flack from the debhelper maintainer for making independent changes in the past ([1], [2]), and doing so again seems like a bad plan.
dh_install already has a --fail-missing option. It seems that this would cover half of your use case, though I gather there are some outstanding issues with it ([3]). CDBS also has a list-missing target, though it doesn't seem that it can be made to fail the build, and also doesn't cover your overlapping files issue.
It seems like it would be much more productive to work with Joey to try and fix dh_install --fail-missing, and possibly add a new --fail-on-overlap option or something. But in any case, I think that adding a new debhelper script without consulting Joey at all will hurt Ubuntu's image in Debian's eyes, and that's a bad thing.
- Evan
[1] http://kitenet.net/~joey/blog/entry/on_forking_debhelper/ [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=369755 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453693
W dniu 03.06.2011 21:17, Evan Broder pisze:
Ubuntu has gotten quite a bit of flack from the debhelper maintainer for making independent changes in the past ([1], [2]), and doing so again seems like a bad plan.
Perhaps posting this from my @canonical.com address was a bad idea. I'm not doing this as a Canonical employee, nor as a ubuntu developer. I'm doing this as an upstream (actually working on Linaro tools) that uses Debian/Ubuntu as the delivery platform.
My response below may seem to be quite harsh but I hope to keep it factual.
For context. I wrote dh_splitpackage yesterday after being upset with dh_install and failing to find any packages that would do what I wanted easily. I did it while packaging the tools I'm developing daily so that my users can install them easily. Nothing in this has any relation to my employer, Canonical, Ubuntu or Linaro. I made this and the fault, if any, is mine.
dh_install already has a --fail-missing option. It seems that this would cover half of your use case,
To the best of my knowledge dh_install cannot do what I wish. Well, I could copy file by file, directory by directory, carefully observing the right paths, adding exclusion patterns and so on.
That's not my goal.
My goal is to split a package (which I understand as "move each file from debian/tmp into the appropriate sub-package") easily, without too much, error-prone, shell scripting and without doubts I missed something and it's actually failing silently (or will fail silently when upstream files move around later).
though I gather there are some outstanding issues with it ([3]). CDBS also has a list-missing target, though it doesn't seem that it can be made to fail the build, and also doesn't cover your overlapping files issue.
See, that's not solving my problem.
It seems like it would be much more productive to work with Joey to try and fix dh_install --fail-missing, and possibly add a new --fail-on-overlap option or something.
Productive for who? I never even knew Joey (no disrespect to him). I solved my problem and shared the solution. My problem is solved. Better yet, I did not make the general problem worse.
Look at this as a contribution to possible pool of solutions that the greater Debian community may choose to adopt.
But in any case, I think that adding a new debhelper script without consulting Joey at all will hurt Ubuntu's image in Debian's eyes, and that's a bad thing.
I'm sorry I did not know Joey. Perhaps if I was working on packaging lots of 3rd party software I would get know him eventually. Should that prevent me (or anyone) from coming up with a good technical solution to a problem? Even if dh_splitpackage will rot in the internet archive it _did_ solve my problem and I _did_ share the solution hoping for the best.
Now for some rants of my own:
Let's play a game that I did knew Joey or other dh_* maintainers. IMHO engaging in platform development would be pointless. It might end up being political. It would most likely drag on and on, possibly never reaching a consensus. It might require me to rewrite the script in perl, shell or another language. And it could easily fail.
Why would I engage in any of that? Why would any upstream do? (and see how friendly upstream I am to even share my solution with anyone, do you think random upstream developer would?). Debian is an insanely complex political being, with many rules that are fully versed only by people that dwell in this environment for many years. That's not a good ISV environment. Perhaps this is not a popular view but IMHO it's rather true (why would I be writing this email otherwise?)
Getting involved in fixing the platform the way Debian maintainers and many of my colleagues at Canonical do would be diverging from my goals. I'm an upstream working on a project. This project is not Debian. Getting involved with Debian, dh_* maintainers, authors and contributors, while noble, would prevent me from attaining my goal on a predictable and timely basis, which is to get the software I'm working on into the hands of my users.
End of rant.
Now I understand that you had no bad intentions towards me and this is all caused by me posting from @canonical.com without giving any kind of explanation on why I did this.
Sincerely Zygmunt Krynicki
-
Evan Broder -
Zygmunt Krynicki -
Zygmunt Krynicki