© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
Hello Roland.
My name is Harald and I am core developer of Ubuntu.
Regarding the suggested changes I have to agree with the previous commenters. The way the package is built is exactly according to the Debian Policy Manual [1] which defines precisely what a good and reliable package should look like and how it should behave and integrate in the surrounding system.
In comment #3 [2] you are referring to documentation that you apparently followed to create the package. I would very much like to know where I may find this, as it is (obviously) incorrect. Also the Ubuntu project generally does not encourage building own packages to replace official ones, as this prevents any official support of any kind.
In particular at the point where you create your own package you become maintainer of that altered package and neither the Ubuntu community nor Canonical are in any way responsible for the resulting package(s) (most importantly they will not receive security updates obviously).
In that context I might also direct your attention to point 4.9 [3] of the Debian Policy Manual which outlines the behavior of a correct and proper debian/rules file. In particular you might want to read the part about the clean target.
If I may quote just a part of it:
"This [the clean target] must undo any effects that the build and binary targets may have had [...]"
Due to this the change you explicitly proposed is in direct violation of the Debian Policy Manual and could not possibly be included at any rate. By deleting a file in the debian/ directory it is gone forever, meaning that after one build, executing the clean target will not put the source package back into its original state. This is absolutely unacceptable behavior as I am sure you will understand.
As for the need of change in general and the modifications you requested in particular. As I already mentioned the package in its current state is valid and a result of application of sound and proven engineering principles for Makefiles in general and debian/rules files in particular. The changes you proposed introduce maintenance overhead and increase the overall code base, making it essentially more error prone. Primarily however the changes do not have any positive affect (or any for that matter) on the Qt packages in Ubuntu as those are, and also will be in the future, built with plugins rather than static binaries. Surely you are aware of the implications that static compilation has with regards to maintenance, especially in the context of security. It is exactly those implications that make it less than desirable to have static compiled parts anywhere in the system.
I do however acknowledge your desire for this kind of functional and propose the following.
Since your proposed changes do not bring any additional value to the Ubuntu binary packages of Qt the additional code and logic required would introduce overhead in the assurance of various software quality attributes, and is thus not fit for inclusion. However if you were to compensate for the introduced overhead I am reasonably sure an acceptable solution could be reached.
You can either enter a contract with Canonical [4] the primary sponsor of the Ubuntu community, or you could commit to financial support of the Kubuntu community [5] who happens to be primary maintainer of the Qt packages in Ubuntu.
Since your request is not acceptable as-is any further re-opening of this bug report will only result in prompt closing without comment from now on. You can reach me at <email address hidden> should you feel the need for further discussion.
Best regards,
Harald
[1] http://
[2] https:/
[3] http://
[4] http://
[5] http://