Re: ldconfig-symlink-missing-for-shlib error
On Thu, Jul 14, 2005 at 01:25:24AM -0400, kamaraju kusumanchi wrote: I am trying to package fortranposix library. I produced some debian packages but I am not satisfied with their quality. For example, when I do $lintian -i libfortranposix0_0.1-1_i386.deb E: libfortranposix0: ldconfig-symlink-missing-for-shlib usr/lib/libfortranposix.so.0 usr/lib/libfortranposix.so.0.0.0 libfortranposix.so.0 N: N: The package should not only include the shared library itself, but N: also the symbolic link which ldconfig would produce. (This is N: necessary, so that the link gets removed by dpkg automatically when N: the package gets removed.) If the symlink is in the package, check N: that the SONAME of the library matches the info in the shlibs file. N: N: Refer to Policy Manual, section 8.1 for details. N: I thought ldconfig automatically creates the necessary symbolic links provided the postinst, postrm scripts invoke ldconfig properly. Please see Policy section 8.1. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: ldconfig-symlink-missing-for-shlib error
On Thu, 2005-07-14 at 01:25 -0400, kamaraju kusumanchi wrote: I am trying to package fortranposix library. I produced some debian packages but I am not satisfied with their quality. For example, when I do $lintian -i libfortranposix0_0.1-1_i386.deb E: libfortranposix0: ldconfig-symlink-missing-for-shlib usr/lib/libfortranposix.so.0 usr/lib/libfortranposix.so.0.0.0 libfortranposix.so.0 N: N: The package should not only include the shared library itself, but N: also the symbolic link which ldconfig would produce. (This is N: necessary, so that the link gets removed by dpkg automatically when N: the package gets removed.) If the symlink is in the package, check N: that the SONAME of the library matches the info in the shlibs file. N: N: Refer to Policy Manual, section 8.1 for details. N: I thought ldconfig automatically creates the necessary symbolic links provided the postinst, postrm scripts invoke ldconfig properly. ldconfig does at least two things: * update the loader cache * add missing symlinks based on the SONAME store in the library However it can't remove these symlinks automatically. Therefore Debian regards the autocreation of the symlinks as a hack and requires the package to install the proper symlinks in the usual way, so they can be removed in the usual way along with the library when the package is removed. So ldconfig is called in postinst to update the loader cache, not to install the symlinks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldconfig-symlink-missing-for-shlib error
On Thu, 2005-07-14 at 01:53 -0400, kamaraju kusumanchi wrote: section 8.1 of debian-policy states that [sic]The run-time library package should include the symbolic link that |ldconfig| would create for the shared libraries. [sic] Does not this mean that ldconfig creates the symbolic link for the shared libraries? Yes. But consider these two scenarios: (A) You supply the library not the link Install: * library installed by package * link create by postinst script running ldconfig Removal: * library removed by package manager NOTE: the link is not removed! (B) You supply the library AND the link Install: * library installed by package * link installed by package Removal: * library removed by package manager * link removed by package manager NOTE: the library AND the link are removed this way So this is the reason for the Policy: to ensure the library AND the link are removed when the package is. * ldconfig creates links, but doesn't remove them * ldconfig is still run in the postinst script for a different reason: to update the dynamic loaders cache immediately after the package is installed The cache makes it faster to find shared libraries. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldconfig-symlink-missing-for-shlib error
Steve Langasek wrote: On Thu, Jul 14, 2005 at 01:25:24AM -0400, kamaraju kusumanchi wrote: I am trying to package fortranposix library. I produced some debian packages but I am not satisfied with their quality. For example, when I do $lintian -i libfortranposix0_0.1-1_i386.deb E: libfortranposix0: ldconfig-symlink-missing-for-shlib usr/lib/libfortranposix.so.0 usr/lib/libfortranposix.so.0.0.0 libfortranposix.so.0 N: N: The package should not only include the shared library itself, but N: also the symbolic link which ldconfig would produce. (This is N: necessary, so that the link gets removed by dpkg automatically when N: the package gets removed.) If the symlink is in the package, check N: that the SONAME of the library matches the info in the shlibs file. N: N: Refer to Policy Manual, section 8.1 for details. N: I thought ldconfig automatically creates the necessary symbolic links provided the postinst, postrm scripts invoke ldconfig properly. Please see Policy section 8.1. The error message already told me to do that. I ofcourse read this incomprehensible 8.1 section of the debian-policy before posting my question here. The wording in this section is so cryptic that it really does not help attracting new maintainers. I mean, the maint-guide is so good, but this debian-policy is not upto that. Just yesterday, I posted for a clarification of the wording in 8.1.1 . http://groups-beta.google.com/group/linux.debian.devel.mentors/browse_thread/thread/de6df3a594904f43/064f698ea912845c?hl=en#064f698ea912845c May be I am not yet ready for packaging debian stuff... But I would like to try anyway. Can you tell me where in this section 8.1, does it say that the maintainer has to create a symbolink for a runtime library package? The thing that comes close is the following paragraph. The run-time library package should include the symbolic link that |ldconfig| would create for the shared libraries. For example, the |libgdbm3| package should include a symbolic link from |/usr/lib/libgdbm.so.3| to |libgdbm.so.3.0.0|. This is needed so that the dynamic linker (for example |ld.so| or |ld-linux.so.*|) can find the library between the time that |dpkg| installs it and the time that |ldconfig| is run in the |postinst| script. According to this paragraph ldconfig should take care of creating the links. Other replies to this thread suggest that ldconfig is not used for this purpose while packaging .debs. If that is correct, then section 8.1 of policy has to be rewritten (since it conveys wrong information). thanks raju -- Kamaraju S Kusumanchi Graduate Student, MAE Cornell University http://www.people.cornell.edu/pages/kk288/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: zoo: directory traversal security bug
Ganesan Rajagopal wrote: Not to me. I don't think it's a requirement to know C to maintain a package. Well, how about if the package's source is 1 lines of C code? I do prefer people knowing what it actually is they're putting into the archive. 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: ldconfig-symlink-missing-for-shlib error
skaller wrote: On Thu, 2005-07-14 at 01:53 -0400, kamaraju kusumanchi wrote: section 8.1 of debian-policy states that [sic]The run-time library package should include the symbolic link that |ldconfig| would create for the shared libraries. [sic] Does not this mean that ldconfig creates the symbolic link for the shared libraries? Yes. But consider these two scenarios: other stuff snipped Thanks for your clarification. I seriously think that section 8.1 need to completely rewritten and should include your explanation in there. In a document like debian-policy, It is important to give what someone should do and why they should do it so. The 'why', I guess is very important. raju -- Kamaraju S Kusumanchi Graduate Student, MAE Cornell University http://www.people.cornell.edu/pages/kk288/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Not able to understand debian-policy 8.1.1
On 13-Jul-2005, Ben Finney wrote: Is that clearer? If so, I'll suggest a change to debian-policy. I've filed a bug against debian-policy, with a patch rewording that paragraph. URL:http://bugs.debian.org/318214 -- \I went to court for a parking ticket; I pleaded insanity. I | `\ said 'Your Honour, who in their right mind parks in the passing | _o__)lane?' -- Steven Wright | Ben Finney [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: ldconfig-symlink-missing-for-shlib error
On Thu, Jul 14, 2005 at 04:18:15AM -0400, kamaraju kusumanchi wrote: Please see Policy section 8.1. The error message already told me to do that. I ofcourse read this incomprehensible 8.1 section of the debian-policy before posting my question here. The wording in this section is so cryptic that it really does not help attracting new maintainers. I mean, the maint-guide is so good, but this debian-policy is not upto that. Just yesterday, I posted for a clarification of the wording in 8.1.1 . http://groups-beta.google.com/group/linux.debian.devel.mentors/browse_thread/thread/de6df3a594904f43/064f698ea912845c?hl=en#064f698ea912845c May be I am not yet ready for packaging debian stuff... But I would like to try anyway. Can you tell me where in this section 8.1, does it say that the maintainer has to create a symbolink for a runtime library package? The thing that comes close is the following paragraph. The run-time library package should include the symbolic link that ^^ |ldconfig| would create for the shared libraries. ^ I'm sorry, I don't see any way that Policy could be rewritten to make the very first sentence that you quoted any clearer. According to this paragraph ldconfig should take care of creating the links. Other replies to this thread suggest that ldconfig is not used for this purpose while packaging .debs. If that is correct, then section 8.1 of policy has to be rewritten (since it conveys wrong information). The *package* should *include* the *symbolic link*. I think Policy is already very clear on this point. Policy doesn't care how you get the symlink *into* the package, if that's what you're asking; it only requires that the symlink provided by the package be the same one that ldconfig *would* create. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Not able to understand debian-policy 8.1.1
Ben Finney wrote: On 13-Jul-2005, Ben Finney wrote: Is that clearer? If so, I'll suggest a change to debian-policy. I've filed a bug against debian-policy, with a patch rewording that paragraph. URL:http://bugs.debian.org/318214 Wow. That's really fast. Thanks for taking the time to file the bug report and giving them the patch also. It will probably help someone in the future. raju -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldconfig-symlink-missing-for-shlib error
Philipp Kern wrote: On Thu, 2005-07-14 at 01:53 -0400, kamaraju kusumanchi wrote: section 8.1 of debian-policy states that [sic]The run-time library package should include the symbolic link that |ldconfig| would create for the shared libraries. [sic] Does not this mean that ldconfig creates the symbolic link for the shared libraries? In this case, correct me if I am wrong, ldconfig should create libfortranposix.so.0 which should point to libfortranposix.0.0.0 According to the policy you have to provide them by yourself in your run-time library package (e.g. libfortranposix0). Kind regards, Philipp Kern Based on other replies to this thread, I understand that, I have to create the link myself in the run-time library package. I also understand the reason for not employing ldconfig to do that. But can you please tell me, where in the policy does it say that? I could have missed it while reading and would like to know which sentences convey this information. Please dont just give the section numbers, I am looking for some sentences quoted from the debian-ploicy here. thanks raju -- Kamaraju S Kusumanchi Graduate Student, MAE Cornell University http://www.people.cornell.edu/pages/kk288/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldconfig-symlink-missing-for-shlib error
On 05/07/14 04:42 -0400, kamaraju kusumanchi said ... But can you please tell me, where in the policy does it say that? I could have missed it while reading and would like to know which sentences convey this information. Please dont just give the section numbers, I am looking for some sentences quoted from the debian-ploicy here. Quoting from http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime 8.1 Run-time shared libraries [snip] The run-time library package should include the symbolic link that ldconfig would create for the shared libraries. For example, the libgdbm3 package should include a symbolic link from /usr/lib/libgdbm.so.3 to libgdbm.so.3.0.0. 8.1.1 ldconfig [snip] Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldconfig-symlink-missing-for-shlib error
Steve Langasek wrote: On Thu, Jul 14, 2005 at 04:18:15AM -0400, kamaraju kusumanchi wrote: Can you tell me where in this section 8.1, does it say that the maintainer has to create a symbolink for a runtime library package? The thing that comes close is the following paragraph. The run-time library package should include the symbolic link that ^^ |ldconfig| would create for the shared libraries. ^ I'm sorry, I don't see any way that Policy could be rewritten to make the very first sentence that you quoted any clearer. After reading your email (especially the last couple of sentences), it dawned on me as to what the policy is trying to say. Let me first tell how I interpreted it and then I will provide some possible improvement. From the above sentence, I initially thought that ldconfig would create the symbolic link for the actual shared library. The run-time library package then should include this symbolic link in it. One possible alteration would be (with minimal changes to the original text) The run-time library package should include the symbolic link to the shared libraries that| |would have normally been created by ldconfig. This link has to be created by the maintainer. For example, the |libgdbm3| package should include a symbolic link from |/usr/lib/libgdbm.so.3| to |libgdbm.so.3.0.0|. This is needed so that the dynamic linker (for example |ld.so| or |ld-linux.so.*|) can find the library between the time that |dpkg| installs it and the time that |ldconfig| is run in the |postinst| script. Another possible alteration could be (completely rewritten) ldconfig can be used to create necessary symbolic links for a given shared object. However, it cannot be used to remove these symbolic links when the package is removed. For this reason, it is required to manually create and remove the symbolic link in the runtime library. Consider for example the libgdbm3 package which creates libgdbm.so.3.0.0. Normally running ldconfig on this, would create a file /usr/lib/libgdbm.so.3 which points to libgdbm.so.3.0.0. But for reasons suggested before, this link has to be created by the maintainer. According to this paragraph ldconfig should take care of creating the links. Other replies to this thread suggest that ldconfig is not used for this purpose while packaging .debs. If that is correct, then section 8.1 of policy has to be rewritten (since it conveys wrong information). The *package* should *include* the *symbolic link*. I think Policy is already very clear on this point. Policy doesn't care how you get the symlink *into* the package, if that's what you're asking; it only requires that the symlink provided by the package be the same one that ldconfig *would* create. That last sentence is what made me see the real meaning. thanks raju -- Kamaraju S Kusumanchi Graduate Student, MAE Cornell University http://www.people.cornell.edu/pages/kk288/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldconfig-symlink-missing-for-shlib error
Kapil Hari Paranjape wrote: Hello, On Thu, Jul 14, 2005 at 04:18:15AM -0400, kamaraju kusumanchi wrote: Can you tell me where in this section 8.1, does it say that the maintainer has to create a symbolink for a runtime library package? The thing that comes close is the following paragraph. The run-time library package should include the symbolic link that |ldconfig| would create for the shared libraries. I think that the policy seems to speak pretty plain english here. Let me underline the relevant words again: The run-time library package should include the symbolic link that ^^ |ldconfig| would create for the shared libraries. In other word your package should *already* include the link that ldconfig would *have* created (were it given the chance to do so). Regards, Kapil. -- Thanks. I read it as that ldconfig would create . Also I appreciate if you keep replied on the list. raju -- Kamaraju S Kusumanchi Graduate Student, MAE Cornell University http://www.people.cornell.edu/pages/kk288/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldconfig-symlink-missing-for-shlib error
On Thu, Jul 14, 2005 at 05:17:12AM -0400, kamaraju kusumanchi wrote: One possible alteration would be (with minimal changes to the original text) The run-time library package should include the symbolic link to the shared libraries that| |would have normally been created by ldconfig. I don't think this is a good formulation. It depends on your definition of what's normal. I think on a Debian system, anything dictated by policy is normal. So according to that rule, ldconfig wouldn't normally create any symlinks, because they are already included in the package. If the wording needs to be changed, I'd suggest something like that would otherwise be created by ldconfig. This link has to be created by the maintainer. For example, the |libgdbm3| package should include a symbolic link from |/usr/lib/libgdbm.so.3| to |libgdbm.so.3.0.0|. This is needed so that the dynamic linker (for example |ld.so| or |ld-linux.so.*|) can find the library between the time that |dpkg| installs it and the time that |ldconfig| is run in the |postinst| script. As far as I understand it, this is incorrect. The links are not provided for use during this time, they are provided because they must be erased again during package removal. 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: zoo: directory traversal security bug
I thought to be a mantainer I just must know debian-policy, how to create Debian package,, how to create docs,etc . I read many Debian Docs, and I didnt read anything about people must be C, python, php ,etc developer. [] Jose Carlos Ganesan Rajagopal wrote: Not to me. I don't think it's a requirement to know C to maintain a package. Well, how about if the package's source is 1 lines of C code? I do prefer people knowing what it actually is they're putting into the archive. Kind regards T. -- José Carlos do Nascimento [EMAIL PROTECTED] Analista de Sistemas VARIG Brazilian Airlines - SAODT GGTI - Gerencia Geral de Tecnologia da Informação Tel.: + 55-0XX-11-5091-2632 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Sponsor needed for ktorrent package
I have packaged ktorrent 1.0 and am looking for a sponsor to verify packages and do the actual upload KTorrent homepage: http://ktorrent.pwsp.net/ ITP - http://bugs.debian.org/313659 Thanks, Joel Johnson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Macromedia Studio MX 2004 - $54.95
Microsoft Windows XP Professional with SP2 Corporate Edition - $54.95 AutoCAD 2005 - $69.95 Microsoft Office System Professional 2003 - $54.95 Adobe Photoshop Elements 3.0 - $19.95 and much more. at http://replacesoft.com/?a=3331 with fr e e e bonus. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor needed for ktorrent package
On Thu, Jul 14, 2005 at 09:04:30AM -0700, Joel Johnson wrote: I have packaged ktorrent 1.0 and am looking for a sponsor to verify packages and do the actual upload KTorrent homepage: http://ktorrent.pwsp.net/ ITP - http://bugs.debian.org/313659 Where is the Debian source package? Anyway, note that this is a pretty _bad_ moment to upload C++-related packages, so don't expect an upload in the next weeks or so... -- Esteban Manchado Velázquez [EMAIL PROTECTED] - http://www.foton.es EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor needed for ktorrent package
Hi, * Joel Johnson [EMAIL PROTECTED] [2005-07-14 19:58]: I have packaged ktorrent 1.0 and am looking for a sponsor to verify packages and do the actual upload KTorrent homepage: http://ktorrent.pwsp.net/ ITP - http://bugs.debian.org/313659 Please include the information you gave in the ITP into the RFS and link a page for the source package. Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgp9cbpxchVT9.pgp Description: PGP signature
RFS: libXvMCW (again)
Hello again, A while ago I asked for a sponsor for the XvMC wrapper library (http://lists.debian.org/debian-mentors/2005/06/msg00115.html). Now that Debian has the XOrg packages required to build it, I'm asking again. Formalities: Name: libxvmcw Homepage: http://sourceforge.net/projects/unichrome License: GPL Description: Client library for the XvMC wrapper The XVideo Motion Compensation wrapper library is a vendor-neutral interface that wraps calls to any and all hardware-specific XvMC implementations. . Linking should always use the wrapper instead of any hardware-specific XvMC implementation. This way, dependencies on unnecessary packages are not created just to include hardware accelerated video decoding. The packages are available at my own apt repo: http://www.csd.uwo.ca/~mfgalizi/debian Thanks again! -- Micah F. Galizia [EMAIL PROTECTED] The mark of an immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one. --W. Stekel signature.asc Description: This is a digitally signed message part
Re: zoo: directory traversal security bug
Jose Carlos do Nascimento wrote: I do prefer people knowing what it actually is they're putting into the archive. I thought to be a mantainer I just must know debian-policy, how to create Debian package,, how to create docs,etc . I read many Debian Docs, and I didnt read anything about people must be C, python, php ,etc developer. Well, maybe that's the general sentiment. Looking at the original problem, namely that zoo has a security bug and the maintainer can't fix it by himself because he's not proficient enough in the source language, you might or might not see a point in what I'm suggesting. It won't matter much, because there's plenty of people who don't care about maintainers being able to fix their packages' source if needed. 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: zoo: directory traversal security bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jose Carlos do Nascimento [EMAIL PROTECTED] writes: I thought to be a mantainer I just must know debian-policy, how to create Debian package,, how to create docs,etc . I read many Debian Docs, and I didnt read anything about people must be C, python, php ,etc developer. Being a maintainer is more than knowing good packaging practices. If you aren't able to dive into the source and tinker with it, you won't be able to investigate user bug reports and patch them, evaluate patches others provide, selectively include upstream changes to fix bugs, deal with security issues, etc.. If you can't hack on the source, you can only do ¼ of what the job requires. What if a porter reports a platform-specific bug, and it requires you to investigate and patch it? If you can't understand what you are packaging, you shouldn't be packaging it, IMHO. - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFC1vDzVcFcaSW/uEgRAnn2AKC17XrJYUxBE5mqR9eXjpw88Tlk8QCfWci8 M99r3+Le5rvbibOOJ9IBWyw= =638J -END PGP SIGNATURE-
Re: zoo: directory traversal security bug
On Fri, Jul 15, 2005 at 12:10:50AM +0100, Roger Leigh wrote: If you can't understand what you are packaging, you shouldn't be packaging it, IMHO. So maybe our documentation should state that? I mean something like if your're going to package something written in Python it is highly recommended to KNOW python, and if you're going to package something written in C it is highly recommended to know C ? 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: zoo: directory traversal security bug
* Bartosz Fenski aka fEnIo [EMAIL PROTECTED] [2005-07-15 01:20:44 +0200]: On Fri, Jul 15, 2005 at 12:10:50AM +0100, Roger Leigh wrote: If you can't understand what you are packaging, you shouldn't be packaging it, IMHO. So maybe our documentation should state that? I mean something like if your're going to package something written in Python it is highly recommended to KNOW python, and if you're going to package something written in C it is highly recommended to know C ? regards fEnIo Having a good relationship with upstream helps immensely especially if the maintainer doesn't know C or C++ or whatever the software is written in. Maybe that should be in the policy, too ;) We really should not take it to the absurd extremes. Regards, Alex signature.asc Description: Digital signature
What should I call the source package?
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#naminglibpkg provides guidelines for naming the binary packages. Is there any convention for naming the source packages? I am trying to build fortranposix library whose upstream is located at http://sourceforge.net/projects/fortranposix After compiling it, I will get two libraries (runtime and development libraries). I named these packages as libfortranposix0, libfortranposix0-dev according to their soname. But I am not sure what the name of the source package should be? Should it be fortranposix or libfortranposix or libfortranposix0? Also can you please tell against which package name I should file the ITP? ie against the name of the source or against the name of the binary package? Is it sufficient to file just 1 ITP for all these three packages (source, runtime library, development library) as they are all built from the same source? or should I file 3 different ITPs for each? thanks in advance raju -- Kamaraju S Kusumanchi Graduate Student, MAE Cornell University http://www.people.cornell.edu/pages/kk288/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should I call the source package?
On Thu, 2005-07-14 at 23:24 -0400, kamaraju kusumanchi wrote: After compiling it, I will get two libraries (runtime and development libraries). I named these packages as libfortranposix0, libfortranposix0-dev according to their soname. It's libfortranposix0 for the runtime library and libfortranposix-dev for the development package. (If you read by chance debian-devel you should ignore the discussion about naming there for now.) But I am not sure what the name of the source package should be? Should it be fortranposix or libfortranposix or libfortranposix0? What's the name of the tarball provided by upstream? You should use that. Both fortranposix and libfortranposix is perfectly acceptable, depending on how the source is usually called. Also can you please tell against which package name I should file the ITP? ie against the name of the source or against the name of the binary package? You should file it with the name of the source package. Not that it matters much, though. But filing it with the current SONAME would not make much sense. Kind regards, Philipp Kern signature.asc Description: This is a digitally signed message part
