Re: RFS: cfi (adopted package, 2nd try)
Hi Please reply to mentors list. Dne Fri, 26 Sep 2008 18:35:20 +0200 Krzysztof Burghardt [EMAIL PROTECTED] napsal(a): 2008/9/25 Michal Čihař [EMAIL PROTECTED]: - doc-base section Books seems to be more appropriate I changed it back, but according to lintian there is no Book section. Oops, sorry it should be Help/Books (just check doc-base documentation if unsure)... -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: RFS: cfi (adopted package, 2nd try)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 2008/9/25 Michal Čihař [EMAIL PROTECTED]: - Why does diff.gz contain cfi-3.0/.log? By mistake. Fixed. - patch-stamp is not a PHONY target Fixed. - doc-base section Books seems to be more appropriate Set to Help/Books now. - why you no longer suggest dvi viewer when package still contains dvi document? There is no xdvi package in unstable. I suggests now tkdvi | xgdvi. Updated package was uploaded to mentors.d.n. Regards, - -- Krzysztof Burghardt [EMAIL PROTECTED] http://www.burghardt.pl/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjgr6MACgkQXgk7638/b1tkxgCeK9YIxbdSikeNUuVW1ygJcF3/ Hf0AoPCxNnxSzVBEEx+o4L+Sq2YNts7T =mM7Y -END PGP SIGNATURE-
RFS: texttrainer
Dear mentors, I am looking for a sponsor for my package texttrainer. * Package name: texttrainer Version : 0.0.1 Upstream Author : Jacob Kanev [EMAIL PROTECTED] * URL : http://home.arcor.de/j_kanev/ * License : GPL Section : misc It builds these binary packages: texttrainer - learn native or foreign language texts by heart The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/texttrainer - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/texttrainer/texttrainer_0.0.1.dsc I would be glad if someone uploaded this package for me. Kind regards Jacob Kanev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
how to install package using apt-get in folder other than /usr
Hi.. Can someone help me regarding how to install a package in any user defined folder other than /usr using apt-get? Thanks for the help -- View this message in context: http://www.nabble.com/how-to-install-package-using-apt-get-in-folder-other-than--usr-tp19723203p19723203.html Sent from the debian-mentors mailing list archive at Nabble.com. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to install package using apt-get in folder other than /usr
On Mon, 29 Sep 2008 05:45:20 -0700 (PDT) Kruti [EMAIL PROTECTED] wrote: Hi.. Can someone help me regarding how to install a package in any user defined folder other than /usr using apt-get? Not using apt, using dpkg-deb -x. -x, --extract archive directory Extracts the filesystem tree from a package archive into the specified directory. apt-cross can help you get the actual .deb (whether the architecture matches or not) or you can just go to the packages.debian.org website and download the .deb directly from the mirrors. Or use a chroot and install the package normally inside it: $ sudo pbuilder create $ sudo pbuilder login # apt-get install foo # exit -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpwHF7vbwWd7.pgp Description: PGP signature
Re: how to install package using apt-get in folder other than /usr
On Mon, Sep 29, 2008 at 8:45 PM, Kruti [EMAIL PROTECTED] wrote: Can someone help me regarding how to install a package in any user defined folder other than /usr using apt-get? Your question lacks detail, can you please give some more infomation so it can be answered correctly? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to install package using apt-get in folder other than /usr
i mean when you do apt-get install package, all the files of the package are installed in /usr.for eg: packge binary in /usr/bin. but if i want the package n all its files to be installed in a directory other than /usr for eg in XYZ directory thn what should i do...thnks Paul Wise-3 wrote: On Mon, Sep 29, 2008 at 8:45 PM, Kruti [EMAIL PROTECTED] wrote: Can someone help me regarding how to install a package in any user defined folder other than /usr using apt-get? Your question lacks detail, can you please give some more infomation so it can be answered correctly? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/how-to-install-package-using-apt-get-in-folder-other-than--usr-tp19723203p19723987.html Sent from the debian-mentors mailing list archive at Nabble.com. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to install package using apt-get in folder other than /usr
On Mon, Sep 29, 2008 at 9:36 PM, Kruti [EMAIL PROTECTED] wrote: i mean when you do apt-get install package, all the files of the package are installed in /usr.for eg: packge binary in /usr/bin. but if i want the package n all its files to be installed in a directory other than /usr for eg in XYZ directory thn what should i do...thnks Sounds like you emailed the wrong list (debian-user would be more appropriate). Anyway, the answer is to manually extract the files, put them where you want them and hope that works. Neil's email says how to do that. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to install package using apt-get in folder other than /usr
On Mon, 2008-09-29 at 06:36 -0700, Kruti wrote: i mean when you do apt-get install package, all the files of the package are installed in /usr.for eg: packge binary in /usr/bin. but if i want the package n all its files to be installed in a directory other than /usr for eg in XYZ directory thn what should i do...thnks The package determines the directories, it is not up to you to change it unless it is your package (and changes must be compliant with Policy) - at which point you have to rebuild the package and set the new directories for use by all users. e.g. dpkg-cross repackages -dev and lib* packages to change files in /usr/lib/ into files going into /usr/arm-linux-gnu/lib and /usr/include files into /usr/arm-linux-gnu/include. Multiarch does a similar thing for 32bit|64bit permutations - again by changing the way that the package is BUILT. Once built, the directories cannot be altered by apt. Use dpkg-deb -x for tests and experimentation, use a chroot to isolate the installation from the rest of the system. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: how to install package using apt-get in folder other than /usr
On Mon, 29 Sep 2008, Kruti wrote: i mean when you do apt-get install package, all the files of the package are installed in /usr.for eg: packge binary in /usr/bin. but if i want the package n all its files to be installed in a directory other than /usr for eg in XYZ directory thn what should i do...thnks Hi, In that case, you can do what Neil Williams said, and using the flag -X (capital x) would extract the package but in verbose mode. Also with the flag -e you will extract the debian/control file. Regards, Mauro -- JID: [EMAIL PROTECTED] http://lusers.com.ar/ 2B82 A38D 1BA5 847A A74D 6C34 6AB7 9ED6 C8FD F9C1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to install package using apt-get in folder other than /usr
Le Mon, Sep 29, 2008 at 02:46:00PM +0100, Neil Williams a écrit : On Mon, 2008-09-29 at 06:36 -0700, Kruti wrote: i mean when you do apt-get install package, all the files of the package are installed in /usr.for eg: packge binary in /usr/bin. but if i want the package n all its files to be installed in a directory other than /usr for eg in XYZ directory thn what should i do...thnks The package determines the directories, it is not up to you to change it unless it is your package (and changes must be compliant with Policy) - Hi Neil, I guess that Kruti meant that if a foobar package has the following files: /usr/bin/foobar /usr/share/man/man1/foobar.1 /etc/foobarrc (...) he would like to install it the files in prefix/bin/foobar prefix/share/man/man1/foobar.1 prefix/etc/foobarrc (or even $Prefix/.config/foobarrc) (...) and that if foobar depends on bazbaz, then with an appropriate apt-get command, bazbaz can be installed in the same prefix. While I would also love to have this feature in Debian, it is indeed offtopic on this list and should better be a wishlist bug of apt-get, aptitude, or any other frontend to dpkg. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to install package using apt-get in folder other than /usr
Hello, On Mon, 29 Sep 2008, Kruti wrote: Can someone help me regarding how to install a package in any user defined folder other than /usr using apt-get? If you just want to examine the contents of the .deb package then you can download the package (e.g. aptitude download pkgname) and unpack it using dpkg -x pkgname target_directory or using ar. Installing a package so that it can be used is more complex since it is likely that the pre-compilation configuration of a binary package set the prefix for the installation as /usr. Hence the package may not work as you expect. Here are some possible solutions: 1. Use an schroot (e.g. this is described in my article http://www.linuxgazette.net/150/kapil.html) This will still be in /usr but under a different directory heirarchy. 2. Use a fakechroot (e.g. this is described in my blog post http://www.imsc.res.in/~kapil/blog/floss/fakeroot-2008-03-04-10-01 The second solution does not require you to re-install all the dependencies of the package that have already been installed. However, it may not work for all packages. Regards, Kapil. -- signature.asc Description: Digital signature
Re: how to install package using apt-get in folder other than /usr
On Mon, 29 Sep 2008 22:55:55 +0900 Charles Plessy [EMAIL PROTECTED] wrote: The package determines the directories, it is not up to you to change it unless it is your package (and changes must be compliant with Policy) - Hi Neil, I guess that Kruti meant that if a foobar package has the following files: /usr/bin/foobar /usr/share/man/man1/foobar.1 /etc/foobarrc (...) he would like to install it the files in prefix/bin/foobar prefix/share/man/man1/foobar.1 prefix/etc/foobarrc (or even $Prefix/.config/foobarrc) (...) Just because someone would like to install that way, does not mean that it is right to do so. and that if foobar depends on bazbaz, then with an appropriate apt-get command, bazbaz can be installed in the same prefix. For what purpose? Multiarch is being developed. Cross-building has existing mechanisms and the two are trying to synchronise before Squeeze. If there are other (valid) reasons for this, where a chroot *cannot* be used, this needs to be within the frame of the discussions. The current changes are difficult enough - get involved if you want to have any input. The chroot IS the preferred and default mechanism for this kind of work - there needs to be a good reason *not* to use it. While I would also love to have this feature in Debian, it is indeed offtopic on this list and should better be a wishlist bug of apt-get, aptitude, or any other frontend to dpkg. No. Before you recommend such a method, be sure that existing support cannot be used and provide a robust reasoning for such a fundamental change to how Debian works. Changes to apt and dpkg must be practicable or the bug would just be closed without comment. Don't waste time with bugs that have no prospect of being even discussed - explain the rationale and ensure that there is a valid purpose for the request. Any changes to directories *must* be done consistently - allowing arbitrary prefixes is an exceedingly bad idea. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpFbCgABGaZ6.pgp Description: PGP signature
Packaging a library
Hi, I'm packing a library (not yet an ITP, just learning) and I'm having some doubts about it. Upstream uses autotools, but not in a very correct way, I guess. The library is 3.5.6 version, but the configure + make creates libXXX.so.0.0.0. I have looked on the configure.ac, Makefile.am, etc, and I have not seen any place to pass a parameter to libtoolize. So, how can I correct this bug in upstream? Also, my second question is about to create a dbg package. Upstream has some --enable-debug that is a -DDEBUG. Looking on the source I have seen some std outs with this define. Looking others packages, I have understood that you create the package normally, and you add dh_strip --dbg-package= line to put the striped symbols in that package. This is correct? is it worsewhile to generate that package? And my last question is examples. Upstream has a directory with some examples, but they are not installed (noinst_PROGRAMS), so, should I to patch sources to install them? Or simply, do I copy the files? Thanks in advance, Leo -- -- Linux User 152692 PGP: 0xF944807E Catalonia signature.asc Description: This is a digitally signed message part.
Re: Packaging a library
On Mon, 29 Sep 2008 17:31:55 +0200 Leopold Palomo Avellaneda [EMAIL PROTECTED] wrote: Hi, I'm packing a library (not yet an ITP, just learning) and I'm having some doubts about it. Upstream uses autotools, but not in a very correct way, I guess. The library is 3.5.6 version, but the configure + make creates libXXX.so.0.0.0. I have looked on the configure.ac, Makefile.am, etc, and I have not seen any place to pass a parameter to libtoolize. So, how can I correct this bug in upstream? IT IS NOT A BUG! The version of a library has nothing to do with the SONAME. Please read the libtool manual. Also, my second question is about to create a dbg package. Upstream has some --enable-debug that is a -DDEBUG. Looking on the source I have seen some std outs with this define. Looking others packages, I have understood that you create the package normally, and you add dh_strip --dbg-package= line to put the striped symbols in that package. This is correct? is it worsewhile to generate that package? It is worthwhile to create the -dbg but let the build tools create it for you. And my last question is examples. Upstream has a directory with some examples, but they are not installed (noinst_PROGRAMS), so, should I to patch sources to install them? Or simply, do I copy the files? noinst_PROGRAMS should not be packaged, generally. Some can be upstream test cases. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpKvvP4YVVCL.pgp Description: PGP signature
Re: Packaging a library
IANADD Leopold Palomo Avellaneda wrote: Hi, I'm packing a library (not yet an ITP, just learning) and I'm having some doubts about it. [snip] Also, my second question is about to create a dbg package. Upstream has some --enable-debug that is a -DDEBUG. Looking on the source I have seen some std outs with this define. Looking others packages, I have understood that you create the package normally, and you add dh_strip --dbg-package= line to put the striped symbols in that package. This is correct? is it worsewhile to generate that package? Yes, it is correct. It's plus to you if you generate this package and for users who want (at some time) to debug it. And my last question is examples. Upstream has a directory with some examples, but they are not installed (noinst_PROGRAMS), so, should I to patch sources to install them? Or simply, do I copy the files? If you can copy the files manually without patching the sources - copy them in install target. General rule is avoiding patching the upstream files whenever possible. -- Eugene V. Lyubimkin aka JackYF signature.asc Description: OpenPGP digital signature
Re: Packaging a library
A Dilluns 29 Setembre 2008, Neil Williams va escriure: On Mon, 29 Sep 2008 17:31:55 +0200 Leopold Palomo Avellaneda [EMAIL PROTECTED] wrote: Hi, I'm packing a library (not yet an ITP, just learning) and I'm having some doubts about it. Upstream uses autotools, but not in a very correct way, I guess. The library is 3.5.6 version, but the configure + make creates libXXX.so.0.0.0. I have looked on the configure.ac, Makefile.am, etc, and I have not seen any place to pass a parameter to libtoolize. So, how can I correct this bug in upstream? IT IS NOT A BUG! The version of a library has nothing to do with the SONAME. Please read the libtool manual. Yes, you are right. But I prefer the Debian library packaging guide, it's more clear in this aspect. However I guess than the author uses the version number as the SONAME number and don't know how to change it. Because I think that the different versions of the library have broken the binary compatibility. But, if I should leave the version numbers as the authors want, no problem. Also, my second question is about to create a dbg package. Upstream has some --enable-debug that is a -DDEBUG. Looking on the source I have seen some std outs with this define. Looking others packages, I have understood that you create the package normally, and you add dh_strip --dbg-package= line to put the striped symbols in that package. This is correct? is it worsewhile to generate that package? It is worthwhile to create the -dbg but let the build tools create it for you. Ok. And my last question is examples. Upstream has a directory with some examples, but they are not installed (noinst_PROGRAMS), so, should I to patch sources to install them? Or simply, do I copy the files? noinst_PROGRAMS should not be packaged, generally. Some can be upstream test cases. In this case are examples. thanks for the answer. best regards, Leo -- -- Linux User 152692 PGP: 0xF944807E Catalonia signature.asc Description: This is a digitally signed message part.
Re: Packaging a library
On Mon, 29 Sep 2008 18:40:47 +0200
Leopold Palomo Avellaneda [EMAIL PROTECTED] wrote:
Upstream uses autotools, but not in a very correct way, I guess. The
library is 3.5.6 version, but the configure + make creates
libXXX.so.0.0.0. I have looked on the configure.ac, Makefile.am, etc, and
I have not seen any place to pass a parameter to libtoolize. So, how can
I correct this bug in upstream?
IT IS NOT A BUG!
The version of a library has nothing to do with the SONAME. Please read
the libtool manual.
Yes, you are right. But I prefer the Debian library packaging guide, it's
more
clear in this aspect. However I guess than the author uses the version number
as the SONAME number and don't know how to change it.
Eh? If the library version is 3.5.6 and the SONAME is 0.0.0, then that
is good and correct.
http://www.gnu.org/software/libtool/manual/libtool.html#Libtool-versioning
Because I think that
the different versions of the library have broken the binary compatibility.
But, if I should leave the version numbers as the authors want, no problem.
Broken binary compatibility between versions that do not currently
exist in Debian are of no consequence to Debian.
What matters is now - educating upstream to tweak the libtool
versioning *separately* from the version string when the ABI next
changes.
Take a look at my own library (upstream and Debian) - QOF.
configure.ac:
AC_INIT([qof],[0.8.0],
[http://lists.sourceforge.net/lists/listinfo/qof-devel])
AC_PREREQ(2.61)
AC_GNU_SOURCE
LIBQOF_LIBRARY_VERSION=2:0:0
LIBQOFSQL_LIBRARY_VERSION=1:1:0
Makefile.am:
libqof_la_LDFLAGS= -version-info $(LIBQOF_LIBRARY_VERSION) \
$(LINKER_SCRIPT) -L${top_builddir}/lib/libsql
That is how the SONAME should be set.
If your upstream are less knowledgeable about libtool and ABI, SONAME
changes, educate them using the libtool manual (they won't care much
about the Debian Library Packaging Guide) and ensure that they update
the LDFLAGS in the relevant Makefile.am to denote when the next
ABI/SONAME change happens.
Also get them to think about gradual SONAME bumps by migrating old
functions to a deprecated.c or similar file with appropriate
conditionals to support a --no-deprecated option to ./configure such
that reverse dependencies can build against the library as it would be
AFTER the SONAME bump and detect problems early.
Packaging libraries is a complex task - do NOT do it unless you are
confident that you can work with upstream to get it right.
If you don't understand the GNU libtool manual, then forget this
package right now. Please don't add another broken library to Debian.
Get them to implement versioned symbols properly as well.
Generally, maintainers should package several ordinary binary
packages BEFORE even considering a library.
And my last question is examples. Upstream has a directory with some
examples, but they are not installed (noinst_PROGRAMS), so, should I to
patch sources to install them? Or simply, do I copy the files?
noinst_PROGRAMS should not be packaged, generally. Some can be upstream
test cases.
In this case are examples.
If you can locate them during the build and they could be useful to
others (without being compiled), then put them
in /usr/share/doc/$package/examples/
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpLGeQ3oQzjH.pgp
Description: PGP signature
Re: Packaging a library
A Dilluns 29 Setembre 2008, Neil Williams va escriure:
On Mon, 29 Sep 2008 18:40:47 +0200
Leopold Palomo Avellaneda [EMAIL PROTECTED] wrote:
Upstream uses autotools, but not in a very correct way, I guess. The
library is 3.5.6 version, but the configure + make creates
libXXX.so.0.0.0. I have looked on the configure.ac, Makefile.am, etc,
and I have not seen any place to pass a parameter to libtoolize. So,
how can I correct this bug in upstream?
IT IS NOT A BUG!
The version of a library has nothing to do with the SONAME. Please read
the libtool manual.
Yes, you are right. But I prefer the Debian library packaging guide, it's
more clear in this aspect. However I guess than the author uses the
version number as the SONAME number and don't know how to change it.
Eh? If the library version is 3.5.6 and the SONAME is 0.0.0, then that
is good and correct.
Yes ... but I guess that upstream have broken the ABI in the several versions
of the library.
http://www.gnu.org/software/libtool/manual/libtool.html#Libtool-versioning
Because I think that
the different versions of the library have broken the binary
compatibility. But, if I should leave the version numbers as the authors
want, no problem.
Broken binary compatibility between versions that do not currently
exist in Debian are of no consequence to Debian.
indeed.
What matters is now - educating upstream to tweak the libtool
versioning *separately* from the version string when the ABI next
changes.
Uff. Who am I to try to educate to upstream? :-) I can try to send an email
about it, but ...
Take a look at my own library (upstream and Debian) - QOF.
you use cdbs ... I don't like it, but it's just my opinion
configure.ac:
AC_INIT([qof],[0.8.0],
[http://lists.sourceforge.net/lists/listinfo/qof-devel])
AC_PREREQ(2.61)
AC_GNU_SOURCE
LIBQOF_LIBRARY_VERSION=2:0:0
LIBQOFSQL_LIBRARY_VERSION=1:1:0
Makefile.am:
libqof_la_LDFLAGS= -version-info $(LIBQOF_LIBRARY_VERSION) \
$(LINKER_SCRIPT) -L${top_builddir}/lib/libsql
That is how the SONAME should be set.
That's what I wanted to know But I will not patch upstream.
If your upstream are less knowledgeable about libtool and ABI, SONAME
changes, educate them using the libtool manual (they won't care much
about the Debian Library Packaging Guide)
Ok, I put the example because Debian Library Packaging Guide explain this kind
of things in a very good way, so, although you don't want to create a debian
package, it gives you a lot of useful information.
and ensure that they update
the LDFLAGS in the relevant Makefile.am to denote when the next
ABI/SONAME change happens.
Ok, I will prepare a mail with all this information to educate upstream.
[...]
Packaging libraries is a complex task - do NOT do it unless you are
confident that you can work with upstream to get it right.
I know that is a complex task, but it's a nice task because you learn a lot of
packaging.
If you don't understand the GNU libtool manual, then forget this
package right now. Please don't add another broken library to Debian.
It's not a question of understanding, I have just said that I prefer how is
explained in the Debian Library Packaging Guide. And, I don't want to add any
broken library, of course.
Get them to implement versioned symbols properly as well.
Ok.
Generally, maintainers should package several ordinary binary
packages BEFORE even considering a library.
Yes, this is the first thing that I thought. But, my main problem is that the
software that I would like to package (because I like or I use or I think
intersting, etc), in general _ALL_ are libraries, so what's supposed that
should I to do?
Package a software that I don't like, or I don't use?
I'm not be able to maintain a package that I don't use/like. I prefer to make
the afford to package something to me important.
[...]
If you can locate them during the build and they could be useful to
others (without being compiled), then put them
in /usr/share/doc/$package/examples/
They are build with autotools, so they are not very useful without a plain
makefile. But I can build one.
On the other hand, you have point me about something important that I have
missed, that it's contact with upstream. So, I will do it.
Thanks for all the comments,
Leo
PS the package is solid
http://www.dtecta.com/files/solid-3.5.6.tgz
SOLID is a software library for collision detection of geometric objects in 3D
space.
--
--
Linux User 152692
PGP: 0xF944807E
Catalonia
signature.asc
Description: This is a digitally signed message part.
Re: Packaging a library
On Mon, 29 Sep 2008 20:08:24 +0200 Leopold Palomo Avellaneda [EMAIL PROTECTED] wrote: Yes, you are right. But I prefer the Debian library packaging guide, it's more clear in this aspect. However I guess than the author uses the version number as the SONAME number and don't know how to change it. Eh? If the library version is 3.5.6 and the SONAME is 0.0.0, then that is good and correct. Yes ... but I guess that upstream have broken the ABI in the several versions of the library. Maybe, but that was then. What matters is now - educating upstream to tweak the libtool versioning *separately* from the version string when the ABI next changes. Uff. Who am I to try to educate to upstream? :-) I can try to send an email about it, but ... You are the Debian Maintainer. You have a responsibility to work with upstream in a cooperative, effective and friendly manner. You need to talk with upstream, persuade them, advise them, recommend changes, listen to them, understand their perspective and make a relationship with them. Take a look at my own library (upstream and Debian) - QOF. you use cdbs ... I don't like it, but it's just my opinion What we are discussing here is not related to the Debian packaging, CDBS is not an issue here. Nothing you do with these SONAME issues needs to have anything to do with CDBS. SONAME work happens upstream, in debian/control and only partially in debian/rules. That is how the SONAME should be set. That's what I wanted to know But I will not patch upstream. No, you should not patch upstream to do things like that. SONAMEs are an upstream decision. You need a relationship with upstream where you listen to them and they listen to you. and ensure that they update the LDFLAGS in the relevant Makefile.am to denote when the next ABI/SONAME change happens. Ok, I will prepare a mail with all this information to educate upstream. Build a relationship first - get on their side and work with them - don't just bash them. [...] Packaging libraries is a complex task - do NOT do it unless you are confident that you can work with upstream to get it right. I know that is a complex task, but it's a nice task because you learn a lot of packaging. And that's your problem - it isn't mostly about packaging, it is about working with upstream to coordinate transitions and ABI changes. If you don't understand the GNU libtool manual, then forget this package right now. Please don't add another broken library to Debian. It's not a question of understanding, I have just said that I prefer how is explained in the Debian Library Packaging Guide. And, I don't want to add any broken library, of course. It *is* about understanding - you must understand the libtool manual so that you can apply the lessons from it to the problems as upstream present them. The Debian Library Packaging Guide might not cut much ice with upstream, the libtool manual commands more respect - once you help them understand it within the context of their library and development patterns. Get to know upstream and work out their workflow then apply your knowledge so that you can offer a solution that they can understand and which they can see has been worked into what they normally do. Generally, maintainers should package several ordinary binary packages BEFORE even considering a library. Yes, this is the first thing that I thought. But, my main problem is that the software that I would like to package (because I like or I use or I think intersting, etc), in general _ALL_ are libraries, so what's supposed that should I to do? Find some other orphaned binary packages to work on? Package a software that I don't like, or I don't use? Use wnpp-alert or rc-alert and find something that you do use. I'm not be able to maintain a package that I don't use/like. I prefer to make the afford to package something to me important. Of course, that is essential to all of us. However, you don't just use libraries - you have to use some binaries, at least some of them could be useful to package, even if you don't try to get them sponsored. [...] If you can locate them during the build and they could be useful to others (without being compiled), then put them in /usr/share/doc/$package/examples/ They are build with autotools, so they are not very useful without a plain makefile. But I can build one. The source code itself is probably useful - hence why I suggested /usr/share/doc/*/examples because then users don't expect to be able to compile them without some effort. It's a case of documentation-by-RTSL -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpNboVHwWb4C.pgp Description: PGP signature
Re: Packaging a library
A Dilluns 29 Setembre 2008, Neil Williams va escriure: [...] What matters is now - educating upstream to tweak the libtool versioning *separately* from the version string when the ABI next changes. Uff. Who am I to try to educate to upstream? :-) I can try to send an email about it, but ... You are the Debian Maintainer. You have a responsibility to work with upstream in a cooperative, effective and friendly manner. You need to talk with upstream, persuade them, advise them, recommend changes, listen to them, understand their perspective and make a relationship with them. OK, explained in this way I like it :-). Take a look at my own library (upstream and Debian) - QOF. you use cdbs ... I don't like it, but it's just my opinion What we are discussing here is not related to the Debian packaging, CDBS is not an issue here. Nothing you do with these SONAME issues needs to have anything to do with CDBS. SONAME work happens upstream, in debian/control and only partially in debian/rules. Arrg!! really we are having difficulties to understand us today. Probably is my fault because I have been very cryptic. I have seen several packages learning how they do that. Using cdbs is a bit opaque to someone who wants to learn. Of course it's nothing to an issue here. Sorry for the noise. That is how the SONAME should be set. That's what I wanted to know But I will not patch upstream. No, you should not patch upstream to do things like that. SONAMEs are an upstream decision. You need a relationship with upstream where you listen to them and they listen to you. Yes, ok. [...] Build a relationship first - get on their side and work with them - don't just bash them. Ok. [...] Yes, this is the first thing that I thought. But, my main problem is that the software that I would like to package (because I like or I use or I think intersting, etc), in general _ALL_ are libraries, so what's supposed that should I to do? Find some other orphaned binary packages to work on? Package a software that I don't like, or I don't use? Use wnpp-alert or rc-alert and find something that you do use. Well, I'm trying to target in the specific area that i use. I'm not be able to maintain a package that I don't use/like. I prefer to make the afford to package something to me important. Of course, that is essential to all of us. However, you don't just use libraries - you have to use some binaries, at least some of them could be useful to package, even if you don't try to get them sponsored. Depend, if you are a developer you use libraries. That was the reason. Regards, Leo -- -- Linux User 152692 PGP: 0xF944807E Catalonia signature.asc Description: This is a digitally signed message part.
Re: how to install package using apt-get in folder other than /usr
On Monday 29 September 2008 15:55:55 Charles Plessy wrote: Hello, Le Mon, Sep 29, 2008 at 02:46:00PM +0100, Neil Williams a écrit : On Mon, 2008-09-29 at 06:36 -0700, Kruti wrote: i mean when you do apt-get install package, all the files of the package are installed in /usr.for eg: packge binary in /usr/bin. but if i want the package n all its files to be installed in a directory other than /usr for eg in XYZ directory thn what should i do...thnks The package determines the directories, it is not up to you to change it unless it is your package (and changes must be compliant with Policy) - Hi Neil, I guess that Kruti meant that if a foobar package has the following files: /usr/bin/foobar /usr/share/man/man1/foobar.1 /etc/foobarrc (...) he would like to install it the files in prefix/bin/foobar prefix/share/man/man1/foobar.1 prefix/etc/foobarrc (or even $Prefix/.config/foobarrc) (...) and that if foobar depends on bazbaz, then with an appropriate apt-get command, bazbaz can be installed in the same prefix. While I would also love to have this feature in Debian, it is indeed offtopic on this list and should better be a wishlist bug of apt-get, aptitude, or any other frontend to dpkg. If I understand you correctly reading the examples given above, I believe you are looking for --instdir=dir option of dpkg. The above-mentioned frontends could pass it to dpkg if necessary. This could be only useful for any weirds experiments, and in all other cases I prefer chroot'ing to a given directory and install/reinstall at will; cowbuilder is your friend. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[OT] Re: how to install package using apt-get in folder other than /usr
Le Mon, Sep 29, 2008 at 03:49:01PM +0100, Neil Williams a écrit : and that if foobar depends on bazbaz, then with an appropriate apt-get command, bazbaz can be installed in the same prefix. For what purpose? Installing Debian packages without administrator privileges and without messing with other users works. Where I work, the calculation machines have a standard system installed (CentOS...), and the way to update and install software is either to request to the (busy) admins to install an (obsolete) CentOS RPM binary package, or to download the upstream tarball and compile everything in our home directory. Actually, for upgrading a program for which one is not the only user this is the only way to go because global update may expose the work of the other users to new bugs. I admit I never asked for a chroot, but can we use chroots without administrator privileges ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] Re: how to install package using apt-get in folder other than /usr
On Tue, 30 Sep 2008 07:06:10 +0900 Charles Plessy [EMAIL PROTECTED] wrote: Le Mon, Sep 29, 2008 at 03:49:01PM +0100, Neil Williams a écrit : and that if foobar depends on bazbaz, then with an appropriate apt-get command, bazbaz can be installed in the same prefix. For what purpose? Installing Debian packages without administrator privileges and without messing with other users works. chroot That is very close to the definitive purpose of using a chroot. Where I work, the calculation machines have a standard system installed (CentOS...), and the way to update and install software is either to request to the (busy) admins to install an (obsolete) CentOS RPM binary package, or to download the upstream tarball and compile everything in our home directory. Actually, for upgrading a program for which one is not the only user this is the only way to go because global update may expose the work of the other users to new bugs. I admit I never asked for a chroot, but can we use chroots without administrator privileges ? Yes. That is how the Debian developer accounts operate. schroot. Someone needs to set up the chroot initially, but once created, schroot can allow usage of the chroot as an ordinary user. http://www.debian-administration.org/articles/566 -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpNaDNp3zitD.pgp Description: PGP signature
