duplicate library code in a package
Hi! I'm packaging kchmviewer, which uses a version of chmlib bundled in the upstream tarball. Is it a Bad Thing to use that library instead of depending on the official packaged one? Regards, -- Tommaso Moroni <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
On Wed, Sep 28, 2005 at 06:15:12PM +0200, Tommaso Moroni wrote: > Hi! > > I'm packaging kchmviewer, which uses a version of chmlib bundled > in the upstream tarball. > > Is it a Bad Thing to use that library instead of depending on the > official packaged one? Yes(TM), it is a Bad Thing(TM). If the official library is suitable, then use it. It will: - absolve you of providing security support for the duplicate code - make the resulting binary packages fewer or smaller - save space on end user systems and repository mirror sites -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpWCsoRy5wEM.pgp Description: PGP signature
Re: duplicate library code in a package
On Wed, 28 Sep 2005, Roberto C. Sanchez wrote: On Wed, Sep 28, 2005 at 06:15:12PM +0200, Tommaso Moroni wrote: Hi! I'm packaging kchmviewer, which uses a version of chmlib bundled in the upstream tarball. Is it a Bad Thing to use that library instead of depending on the official packaged one? Yes(TM), it is a Bad Thing(TM). If the official library is suitable, then use it. It will: - absolve you of providing security support for the duplicate code - make the resulting binary packages fewer or smaller - save space on end user systems and repository mirror sites Don't delete it form the upstream tarball though or your diffs will be huge. Just disable the compilation in the makefiles. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED]http://www.iit.edu/~segre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
On Wed, Sep 28, 2005 at 12:07:08PM -0500, Carlo Segre wrote: > On Wed, 28 Sep 2005, Roberto C. Sanchez wrote: > > >On Wed, Sep 28, 2005 at 06:15:12PM +0200, Tommaso Moroni wrote: > >>Hi! > >> > >>I'm packaging kchmviewer, which uses a version of chmlib bundled > >>in the upstream tarball. > >> > >>Is it a Bad Thing to use that library instead of depending on the > >>official packaged one? > > > >Yes(TM), it is a Bad Thing(TM). > > > >If the official library is suitable, then use it. It will: > > > >- absolve you of providing security support for the duplicate code > >- make the resulting binary packages fewer or smaller > >- save space on end user systems and repository mirror sites > > > > Don't delete it form the upstream tarball though or your diffs will be huge. > Just disable the compilation in the makefiles. > > Carlo An excellent point. I imagine that it would also be permissible to repackage the .orig.tar.gz file so that it is gone from there as well. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpiFM97YzFsQ.pgp Description: PGP signature
Re: duplicate library code in a package
Hello Tommaso, Good thing that you are making a debian of kchmviewer. I myself made a debian package a month back or so.I contacted the developer about the same. I got reply just yesterday. Anyways I have already worked on this, so if you want I can send you the debianised source tar and you can have a look into it. Oh and I had included the chmlib while making the debian but I had a also added an depends entry for the same in the control file. I could install the debian I created in two boxes witout much trouble inspite of getting few warnings from lintian. Would like to have a look at them? I can send them over to you. Regards Pradeepto Bhattacharya On Wed, September 28, 2005 9:45 pm, Tommaso Moroni said: > Hi! > > I'm packaging kchmviewer, which uses a version of chmlib bundled > in the upstream tarball. > > Is it a Bad Thing to use that library instead of depending on the > official packaged one? > > > Regards, > -- > Tommaso Moroni <[EMAIL PROTECTED]> > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > -- Pradeepto Bhattacharya. Email : [EMAIL PROTECTED] Website : http://www.eninteractive.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
On Wednesday 28 September 2005 6:36 pm, Roberto C. Sanchez wrote: > > Don't delete it form the upstream tarball though or your diffs will be > > huge. Just disable the compilation in the makefiles. > > > > Carlo > > An excellent point. I imagine that it would also be permissible to > repackage the .orig.tar.gz file so that it is gone from there as well. ? orig.tar.gz should be as it says - the original. Changes to .org.tar.gz are up to upstream. I use conditional builds on my own projects and when I build the tarball from CVS on Debian, it does not build a library that exists on Debian. However, the tarball is the same as one used to create RPM's on FC3 where the library is NOT available and the build uses the internal code. The upstream tarball and .orig.tar.gz should be as flexible as possible and that means keeping the included files in the source but skipping them in the build of the binary. So package-release.i386.deb uses the external library and has a dependency on it. package-release.src.deb includes the internal code and retains the ability to use the external one if it is present on the *build* system. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpxXC3VN6lUi.pgp Description: PGP signature
Re: duplicate library code in a package
An excellent point. I imagine that it would also be permissible to repackage the .orig.tar.gz file so that it is gone from there as well. ? orig.tar.gz should be as it says - the original. not necessarily. It must be the original, but it must not be pristine. One reason could be to remove autotools dependencies, another could be to remove files which would otherwise be removed by the "clean" target and would end up in a huge diff.gz. IMHO this such things should of course be reported to upstream and hopefully be fixed in the next upstream version. Regards, Andreas -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
On Wed, Sep 28, 2005 at 01:36:02PM -0400, Roberto C. Sanchez wrote: > On Wed, Sep 28, 2005 at 12:07:08PM -0500, Carlo Segre wrote: > > On Wed, 28 Sep 2005, Roberto C. Sanchez wrote: > > > > >On Wed, Sep 28, 2005 at 06:15:12PM +0200, Tommaso Moroni wrote: > > >>Hi! > > >> > > >>I'm packaging kchmviewer, which uses a version of chmlib bundled > > >>in the upstream tarball. > > >> > > >>Is it a Bad Thing to use that library instead of depending on the > > >>official packaged one? > > > > > >Yes(TM), it is a Bad Thing(TM). > > > > > >If the official library is suitable, then use it. It will: > > > > > >- absolve you of providing security support for the duplicate code > > >- make the resulting binary packages fewer or smaller > > >- save space on end user systems and repository mirror sites > > > > > > > Don't delete it form the upstream tarball though or your diffs will be > > huge. > > Just disable the compilation in the makefiles. > > > > Carlo > > An excellent point. I imagine that it would also be permissible to > repackage the .orig.tar.gz file so that it is gone from there as well. Usually only 3 reasons are sufficient justification for repackaging. 1) non DFSG material included; 2) large binaries included; 3) multiple "dependent" upstream source tarballs required for building a single binary package Bill lists some other ones here: http://lists.debian.org/debian-policy/2003/09/msg00123.html My comments within: --- Files have stupid permissions. This is probably not a valid reason, in itself; just run chmod -R u=Xg=o= or whatever in ./debian/rules. --- tarball contains files at the root. As Joerg notes in the New Queue Reject Faq, this is not a valid reason; dpkg-source deals with this just fine. --- Some files are not DFSG free. Correct. --- You can't add binary files (e.g. icons) in a diff. Using uuencode is not optimal. Sometimes it is better to sneak them in the source tarball. That's one way; Theodore Ts'o does it by putting them in the .diff.gz. --- tarball include large stuff that we don't want to package. I think this is only sufficient justification if its very large, like over 50% of the source package size, and tens of megabytes. The other 3 things listed are also okay.. -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
On Wed, 28 Sep 2005, Roberto C. Sanchez wrote: An excellent point. I imagine that it would also be permissible to repackage the .orig.tar.gz file so that it is gone from there as well. -Roberto True, but then there is an additional step to taking a new tarball release and making a package. I think it is better practice not to modify the upstream tarball. Suppose that I were gone and you wanted to package a new release of my package. If I have a special, hidden procedure to prepare the original tarball, then you would not be able to just apply the diffs from the old source and have a chance to make it work. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED]http://www.iit.edu/~segre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
On Wed, Sep 28, 2005 at 12:19:08PM -0400, Roberto C. Sanchez wrote: > > Is it a Bad Thing to use that library instead of depending on the > > official packaged one? > > Yes(TM), it is a Bad Thing(TM). > > If the official library is suitable, then use it. It will: > > - absolve you of providing security support for the duplicate code > - make the resulting binary packages fewer or smaller > - save space on end user systems and repository mirror sites - save someone's memory from loading another library Cause usually they're linking it statically which is another Bad Thing(TM). regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: duplicate library code in a package
On Wed, Sep 28, 2005 at 01:08:47PM -0500, Carlo Segre wrote: > On Wed, 28 Sep 2005, Roberto C. Sanchez wrote: > >An excellent point. I imagine that it would also be permissible to > >repackage the .orig.tar.gz file so that it is gone from there as well. > True, but then there is an additional step to taking a new tarball release > and making a package. I think it is better practice not to modify the > upstream tarball. Suppose that I were gone and you wanted to package a > new release of my package. If I have a special, hidden procedure to > prepare the original tarball, then you would not be able to just apply the > diffs from the old source and have a chance to make it work. See devref section 6.7.8.2: "Repackaged upstream source". -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
On 28 September 2005 14:07, Justin Pryzby wrote: When I make a new upstream package for Erlang, I need to extract the upstream tar.gz file, which is named otp_src_[version].tar.gz, rename the created directory to a Debian friendly name and then make the .orig.tar.gz. Does that count as repackaging? If so I'm clueless as to what I should do to avoid that. > On Wed, Sep 28, 2005 at 01:36:02PM -0400, Roberto C. Sanchez wrote: > > On Wed, Sep 28, 2005 at 12:07:08PM -0500, Carlo Segre wrote: > > > On Wed, 28 Sep 2005, Roberto C. Sanchez wrote: > > > >On Wed, Sep 28, 2005 at 06:15:12PM +0200, Tommaso Moroni wrote: > > > >>Hi! > > > >> > > > >>I'm packaging kchmviewer, which uses a version of chmlib bundled > > > >>in the upstream tarball. > > > >> > > > >>Is it a Bad Thing to use that library instead of depending on the > > > >>official packaged one? > > > > > > > >Yes(TM), it is a Bad Thing(TM). > > > > > > > >If the official library is suitable, then use it. It will: > > > > > > > >- absolve you of providing security support for the duplicate code > > > >- make the resulting binary packages fewer or smaller > > > >- save space on end user systems and repository mirror sites > > > > > > Don't delete it form the upstream tarball though or your diffs will be > > > huge. Just disable the compilation in the makefiles. > > > > > > Carlo > > > > An excellent point. I imagine that it would also be permissible to > > repackage the .orig.tar.gz file so that it is gone from there as well. > > Usually only 3 reasons are sufficient justification for repackaging. > > 1) non DFSG material included; > 2) large binaries included; > 3) multiple "dependent" upstream source tarballs required for > building a single binary package > > Bill lists some other ones here: > http://lists.debian.org/debian-policy/2003/09/msg00123.html > > My comments within: > --- Files have stupid permissions. > This is probably not a valid reason, in itself; just run > chmod -R u=Xg=o= or whatever in ./debian/rules. > > --- tarball contains files at the root. > As Joerg notes in the New Queue Reject Faq, this is not a valid > reason; dpkg-source deals with this just fine. > > --- Some files are not DFSG free. > Correct. > > --- You can't add binary files (e.g. icons) in a diff. Using uuencode > is not optimal. Sometimes it is better to sneak them in the > source tarball. > That's one way; Theodore Ts'o does it by putting them in the .diff.gz. > > --- tarball include large stuff that we don't want to package. > I think this is only sufficient justification if its very large, like > over 50% of the source package size, and tens of megabytes. > > The other 3 things listed are also okay.. > > -- > Clear skies, > Justin pgpukfeHqRiiW.pgp Description: PGP signature
Re: duplicate library code in a package
On Thu, Sep 29, 2005 at 12:05:10AM -0400, Fran?ois-Denis Gonthier wrote: > On 28 September 2005 14:07, Justin Pryzby wrote: > > When I make a new upstream package for Erlang, I need to extract the upstream > tar.gz file, which is named otp_src_[version].tar.gz, rename the created > directory to a Debian friendly name and then make the .orig.tar.gz. > > Does that count as repackaging? If so I'm clueless as to what I should do to > avoid that. Yes. If the .orig.tar.gz is not identical to the upstream source-ball available from the location indicated in the copyright (guaranteed by policy 12.5), then it is considered repackaging. dpkg-source is intelligent, and can deal with many strange upstream tarballs. It doesn't care if the tarball extracts to the wrong directory name, or extracts to ./, or pretty much anything else. You might have to rename the upstream directory for the initial invocation of dh_make, but that it entirely independent from everything else. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
On Thu, 29 Sep 2005, François-Denis Gonthier wrote: On 28 September 2005 14:07, Justin Pryzby wrote: When I make a new upstream package for Erlang, I need to extract the upstream tar.gz file, which is named otp_src_[version].tar.gz, rename the created directory to a Debian friendly name and then make the .orig.tar.gz. Does that count as repackaging? If so I'm clueless as to what I should do to avoid that. YOu should not have to do this every time. The way I have dealt with this issue is the following: 1. make a symbolic link to the original source tarball using the correct Debian name with *_ver.orig.tar.gz 2. untar the original and rename the resulting directory 3. build Debian package in then renamed directory (possibly starting with dh_make) 4. when the next version is released, just download it, make the symbolic link as in (1) and then perform a uupdate inside the previous directory (youcan use the -v option to force a version number if it is not obvious form the tarball name). uupdate will make a new directory with the correct name independent of what is in the tarball 5. better yet, make a watch file and run uscan. if you choose to execute uupdate on the downloaded tarball, it will automagically perform steps in (4) as long as the version number is parseable form the original traball name. The renaming process only needs to be done once and you cactually don't have to re-tar the source. HTH Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED]http://www.iit.edu/~segre
Re: duplicate library code in a package
Hi, Andreas Fester wrote: >>> An excellent point. I imagine that it would also be permissible to >>> repackage the .orig.tar.gz file so that it is gone from there as well. >> >> ? orig.tar.gz should be as it says - the original. > not necessarily. It must be the original, but it must not be pristine. > One reason could be to remove autotools dependencies, another could be > to remove files which would otherwise be removed by the "clean" target > and would end up in a huge diff.gz. Sorry, but I have to point out that your recommendation describes the very opposite of Debian best packaging practices. - Basically, the only reason to repackage upstream is to avoid license problems. Dropping unneccessary stuff might be OK if hundreds of megabytes can be saved, but is generally not OK. - Specifically, if you need to update autotool output, this belongs 100% in the diff.gz (directly or via dpatch et al). It is frowned upon (for good reasons by the qa people) to regenerate at runtime [1]. Also note that deletion of files is ignored for diff.gz creation. Kind regards T. 1. http://sam.zoy.org/lectures/20050910-debian/img17.html -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
Hi, Thomas Viehmann wrote: [...] not necessarily. It must be the original, but it must not be pristine. One reason could be to remove autotools dependencies, another could be to remove files which would otherwise be removed by the "clean" target and would end up in a huge diff.gz. Sorry, but I have to point out that your recommendation describes the very opposite of Debian best packaging practices. I am just not sure how "strong" this practice should be seen. My personal opinion is that the .orig should be as original as possible (with the benefit that its really easy to verify if its identical to the upstream tarball with some MD5 sum), but there are a lot of opposite opinions. [...] - Specifically, if you need to update autotool output, this belongs 100% in the diff.gz (directly or via dpatch et al). Especially regarding autotools output, many other maintainers think different. You end up with a rather huge .diff.gz, and for a lot of people this is reason enough to repackage the upstream tarball. [...] Also note that deletion of files is ignored for diff.gz creation. Yeah, but you get a huge amount of warnings so if you have to repackage anyway, you could also remove those files, even though it might not be good practice to repackage for that reason *only* ... 1. http://sam.zoy.org/lectures/20050910-debian/img17.html Thanks for the pointer to those cool slides :-) Best Regards, Andreas -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
Andreas Fester wrote: >> Sorry, but I have to point out that your recommendation describes the >> very opposite of Debian best packaging practices. > I am just not sure how "strong" this practice should be seen. My Quite frankly, I was disappointed that this recommendation didn't get more criticism. The Developer's Reference Ch. 6.7.8 is very clear and authorative. > >> - Specifically, if you need to update autotool output, this belongs 100% >> in the diff.gz (directly or via dpatch et al). > > Yeah, but you get a huge amount of warnings so if you have to > repackage anyway, you could also remove those files, even though > it might not be good practice to repackage for that reason *only* ... No, sorry. You're supposed to stay as close to pristine as you can. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
On Thu, Sep 29, 2005 at 06:22:43PM +0200, Thomas Viehmann wrote: > Sorry, but I have to point out that your recommendation describes the > very opposite of Debian best packaging practices. > > - Basically, the only reason to repackage upstream is to avoid license > problems. Dropping unneccessary stuff might be OK if hundreds of > megabytes can be saved, but is generally not OK. Agreed. > - Specifically, if you need to update autotool output, this belongs 100% > in the diff.gz (directly or via dpatch et al). Agreed. > It is frowned upon (for good reasons by the qa people) to regenerate > at runtime [1]. I don't agree with the frowning, and I'm not sure if the referenced slide proves your point: > drawbacks: > - Often creates a huge diff > - You will need to take care of timestamps > - Bugs in the autotools are not automatically fixed In particular the last point is something Which I think is important. And what I would also consider a drawback: - It doesn't allow the user to make changes to all source files and have them compiled. Make will try to rerun automake when the Makefile.am changed (I think), but it may not work. > drawbacks of running the autotools during the build: > - Does not require insane build-depends I don't see any problem at all in this. We have Debian, which is full of great software. Why should we be afraid to use it? And really, autotools are not an "insane build depend". Anyone changing and building packages will have them installed anyway. > - You know exactly what is in the autotools files whatever the build > environment Well yes, but at the cost of autotools bugs not being fixed. In general, I would think that if the autotools are going to generate different output, then it's probably because of bugs being fixed. Nothing wrong with using that. However, it does make sense to Build-Depends: on and explicitly call a specific version of aclocal/automake, because different versions of that can have quite different output (or fail to parse input). > Also note that deletion of files is ignored for diff.gz creation. Right, I do delete all generated files (including config.sub, configure, Makefile.in) in the clean target for that reason. > 1. http://sam.zoy.org/lectures/20050910-debian/img17.html Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: duplicate library code in a package
Andreas Fester wrote: > not necessarily. It must be the original, but it must not be pristine. That's self-contradictory. And wrong. > One reason could be to remove autotools dependencies, another could be > to remove files which would otherwise be removed by the "clean" target > and would end up in a huge diff.gz. If you remove files in the clean target they will not appear in your diff.gz. The clean target is run before generating the diff. -- see shy jo signature.asc Description: Digital signature
Re: duplicate library code in a package
Joey Hess wrote: Andreas Fester wrote: not necessarily. It must be the original, but it must not be pristine. That's self-contradictory. And wrong. That's what I learned from other developers during my first packaging experience :-), and its difficult to argue if you are a novice I also thought that .orig *is* what it says, but I have the impression that often people tend to repackage for this or that reason which could also easily be fixed in debian/rules (just reading a similar discussion on d-d). Anyway: I still had the previous version of the developers reference, and the new chapter 6.7.8 talks exactly about this topic, which should help clarifying it when there are doubts. Best Regards, Andreas -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
