Hi,
I was looking at the nice package page at
http://people.debian.org/~igenibel/packages.php?login=yves for my packages
(though it only shows main; why?). I don't understand a few things...
The Sid dependencies says:
BuildDepends
Package declares a build time dependency on
Hi,
I was looking at the nice package page at
http://people.debian.org/~igenibel/packages.php?login=yves for my packages
(though it only shows main; why?). I don't understand a few things...
The Sid dependencies says:
BuildDepends
Package declares a build time dependency on doxygen
On Mon, Feb 25, 2002 at 03:09:58PM -0300, Gustavo Noronha Silva wrote:
The current gphoto2 release is 2.0beta5 wich is packaged as
2.0beta5.
For the final release 2.0, I will package it as 2.0final.
What would be the best numbering scheme for the next beta series
to
On Mon, Feb 25, 2002 at 03:09:58PM -0300, Gustavo Noronha Silva wrote:
The current gphoto2 release is 2.0beta5 wich is packaged as
2.0beta5.
For the final release 2.0, I will package it as 2.0final.
What would be the best numbering scheme for the next beta series
to
Second question: I am making a .deb that is for any platform (it is a
perl script/config files. But when I do the dpkg-buidpackage it makes
the deb blahblahblah_i386.deb although in the config files I have stated
that is for any platform. What am I doing wrong?
Have you said any platform,
Incidentally, why is the source package called 'gphoto2'? I see that
there is still a 'gphoto' package in Debian; is that not superseded by
gphoto 2.0? Are there reasons that someone would need both gphoto and
gphoto2 installed on their system, or why some people need one and
others
Second question: I am making a .deb that is for any platform (it is a
perl script/config files. But when I do the dpkg-buidpackage it makes
the deb blahblahblah_i386.deb although in the config files I have stated
that is for any platform. What am I doing wrong?
Have you said any platform,
Sorry if that's an FAQ. I searched some on archives and didn't find what I
wanted. The next release of ICU may have a library
/usr/lib/libicudt20l.so
which is not recognized by dh_makeshlibs because it has the wrong naming
convention. As a result lintian complains my package
Sorry if that's an FAQ. I searched some on archives and didn't find what I
wanted. The next release of ICU may have a library
/usr/lib/libicudt20l.so
which is not recognized by dh_makeshlibs because it has the wrong naming
convention. As a result lintian complains my package
It looks like I had some stale debhelper files from before I renamed a
package. Anyway, my package now uses DH_COMPAT=2 which is better according
to the manpage for debhelper. I wonder why dh_movefiles requires me to use a
--sourcedir=firstpackageinthecontrolfile though. It should be able to
I changed the subject... dh_clean also leaves the debian/docs file around.
Maybe it's by design too, or should I file a bug?
YA
My guess is that your rules file has:
export DH_COMPAT=2
in it. See debhelper(1). If DH_COMPAT is 1, then debian/tmp is used. If
DH_COMPAT is 2, then debian/name of the first package in debian/control is
used. I guess your control file has a single package, bsf?
You can either change your code
Is anyone on the new-maint guide bit? I wouldn't remember offhand if
DH_COMPAT=1 is deprecated for new packages now.
I am not on the new-maint guide bit, but here's what debhelper(1) says:
V1 Setting DH_COMPAT=1 (or leaving it unset)
causes debhelper
Hi,
I was wondering why dh_clean -A doesn't clean the
debian/packagename.postinst.debhelper file and friends? Any idea?
Thanks,
YA
--
My opinions do not necessarily reflect my company's.
The opposite is also true.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
You ran it manually? I'd guess it's because it defaults to
DH_COMPAT=1, and
your rules file has DH_COMPAT=2...
It cleans up stuff correctly for me.
Hmmm. My rules file (multi package, generated by dh_make) had DH_COMPAT=1 in
it. I rewrote it to use DH_COMPAT=2.
YA
--
To UNSUBSCRIBE,
It looks like I had some stale debhelper files from before I renamed a
package. Anyway, my package now uses DH_COMPAT=2 which is better according
to the manpage for debhelper. I wonder why dh_movefiles requires me to use a
--sourcedir=firstpackageinthecontrolfile though. It should be able to
Hi,
I was wondering why dh_clean -A doesn't clean the
debian/packagename.postinst.debhelper file and friends? Any idea?
Thanks,
YA
--
My opinions do not necessarily reflect my company's.
The opposite is also true.
You ran it manually? I'd guess it's because it defaults to
DH_COMPAT=1, and
your rules file has DH_COMPAT=2...
It cleans up stuff correctly for me.
Hmmm. My rules file (multi package, generated by dh_make) had DH_COMPAT=1 in
it. I rewrote it to use DH_COMPAT=2.
YA
It looks like I had some stale debhelper files from before I renamed a
package. Anyway, my package now uses DH_COMPAT=2 which is better according
to the manpage for debhelper. I wonder why dh_movefiles requires me to use a
--sourcedir=firstpackageinthecontrolfile though. It should be able to
YA $(MAKE) install DESTDIR=`pwd`/debian/tmp
This is dangerous, because if a package use i18n the Makefile
in po/ don't
understand DESTDIR, and all locale aren't installed.
:( :( :(
I guess the Makefile in po/ is autogenerated?
YA
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
Timshel Knoll [EMAIL PROTECTED], wrote:
Try:
./configure --prefix=/usr --sysconfdir=/etc
and then
$(MAKE) install prefix=`pwd`/debian/tmp/usr sysconfdir=`pwd`/tmp/etc
$(sysconfdir) is auto{conf|make}'s /etc directory.
The problem with this method is that when a non-debian
My only thoughts are an evil hack where I edit debian/rules to have
$(MAKE) install prefix=`pwd`/debian/tmp/usr
etcdir=`pwd`/debian/tmp/etc
and then use ${etcdir} for the config file install directory with it
defaulting to /etc in the Makefile.in.
Modifying the Makefile.in and configure.in
YA $(MAKE) install DESTDIR=`pwd`/debian/tmp
This is dangerous, because if a package use i18n the Makefile
in po/ don't
understand DESTDIR, and all locale aren't installed.
:( :( :(
I guess the Makefile in po/ is autogenerated?
YA
Timshel Knoll [EMAIL PROTECTED], wrote:
Try:
./configure --prefix=/usr --sysconfdir=/etc
and then
$(MAKE) install prefix=`pwd`/debian/tmp/usr sysconfdir=`pwd`/tmp/etc
$(sysconfdir) is auto{conf|make}'s /etc directory.
The problem with this method is that when a non-debian
re: DESTDIR -- it's not used in the Makefile.in. I also can't
find it in
'info autoconf' or the html manual...
It's an Automake thing, and people who use Automake typically keep this as a
good idea for their non-Automake packages. Oh well :) Redefining prefix etc.
works quite well too.
YA
Wouldn't this be a case where you want to use recommend?
I *do* use Recommends.
YA.
\
libicu16: just the lib*.so.*
icu: the rest, depends on libicu16.
This is the correct way to do it.
Doesn't this mean that you have to upgrade both packages if you need
to change the *.so.* files in a binary incompatible manner.
Yes.
Ie. wouldn't it be better to have
No. This is a general problem which has yet to be solved. It is not
really the responsibility of the library package to say "I am only
useful for package X". And a Pre-Depends won't be useful. Just have
icu depending on the library package and leave it at that. Note also
that libicu16
\
libicu16: just the lib*.so.*
icu: the rest, depends on libicu16.
This is the correct way to do it.
Doesn't this mean that you have to upgrade both packages if you need
to change the *.so.* files in a binary incompatible manner.
Yes.
Ie. wouldn't it be better to have something
OK, I have this package, libicu16, which contains libraries only. The
libraries are not really useful w/o the data contained in the icu package,
but it is reasonable to expect later libraries to work w/ the same data,
hence the separation. Also, the icu package has binaries which depend on
No. This is a general problem which has yet to be solved. It is not
really the responsibility of the library package to say I am only
useful for package X. And a Pre-Depends won't be useful. Just have
icu depending on the library package and leave it at that. Note also
that libicu16
Hi,
I'm at loss: dh_shlibdeps generates a self-dependency for my library
package. I'm surprised because dh_makeshlibs generated a shlibs file w/ all
the right things for my package, yet dh_shlibdeps adds a self-dependency in
my package's libicu16.substvars.
Any idea how to get rid of that? I
Hi,
I started packaging ICU 1.6 the way libc6 is packaged, or similarly to:
libicu16: contains all the lib*.so.*, plus some /usr/sbin/ tools, plus
some converter data in /usr/share/icu/1.6.0.1/
But then I realized that when ICU 1.7 is released, I'll have:
libicu17: contains all the
Hi Yves,
Any idea why the dh_make-generated rules call $(MAKE) clean
instead of
$(MAKE) distclean, which makes the diffs much smaller? Just
curious...
dh_make-generated rules call "$(MAKE) distclean" if this package has a
configure file and "$(MAKE) clean" if it hasn't one. If the
Hi,
Any idea why the dh_make-generated rules call $(MAKE) clean instead of
$(MAKE) distclean, which makes the diffs much smaller? Just curious...
YA
--
My opinions do not necessarily reflect my company's.
The opposite is also true.
I cannot find a list of all the sections. The only reference to a section is
in the manual for doc-base, but I'd think that a list has been standardized,
no?
YA
--
My opinions do not necessarily reflect my company's.
The opposite is also true.
Hi Yves,
Any idea why the dh_make-generated rules call $(MAKE) clean
instead of
$(MAKE) distclean, which makes the diffs much smaller? Just
curious...
dh_make-generated rules call $(MAKE) distclean if this package has a
configure file and $(MAKE) clean if it hasn't one. If the
In my quest to figure out how to number a prerelease package for ICU that
will be upgraded by icu-1.7-1 (final release), I came up with names like:
1.7.0.pre.20001012
which work w/ dpkg version comparison but also mean that the Debian revision
is non-numeric, as it is 0.pre.20001012. Is
Hi,
I'm sure this is an FAQ. But can I use a version number like:
1.6.20001010-1
and then later on
1.7-1
with success? I want to package something based on date (development
snapshot) but w/o epochs (as I'm not sure where to start the epoch and how
to drop it later). I tried these examples
Hi,
I'm getting these messages from spkg-shlibs:
dpkg-shlibdeps: warning: could not find any packages for (libicu-uc.so.1)
dpkg-shlibdeps: warning: unable to find dependency information for shared
library libicu-uc (soname 1, path , dependency field Depends)
dpkg-shlibdeps: warning: unable to
Epochs are just for when things go wrong. Read the packaging manual,
section 5, carefully.
That's when I got confused :) Not by the manual, by the fact that KDE
packages use (or used to use) epochs while all my tests show it's okay...
Thanks for the clarification that I can do that...
YA
Hi,
I'm sure this is an FAQ. But can I use a version number like:
1.6.20001010-1
and then later on
1.7-1
with success? I want to package something based on date (development
snapshot) but w/o epochs (as I'm not sure where to start the epoch and how
to drop it later). I tried these examples
Epochs are just for when things go wrong. Read the packaging manual,
section 5, carefully.
That's when I got confused :) Not by the manual, by the fact that KDE
packages use (or used to use) epochs while all my tests show it's okay...
Thanks for the clarification that I can do that...
YA
Any well-known trick to compile the .c twice w/o changing
too much of the
original package? For example, does it make sense to
configure in two
different locations, once with --enable-shared and once with
--enable-static, for example? Do we have an example of a
small library that
Alexander Kotelnikov [EMAIL PROTECTED] wrote:
But I want to know where it is written about what should go to -dev
package, and what to the library one.
/usr/share/doc/debian-policy/policy.html/ch4.html#s4.3
/usr/share/doc/packaging-manual/packaging.html/ch-sharedlibs.html
Any
Any well-known trick to compile the .c twice w/o changing
too much of the
original package? For example, does it make sense to
configure in two
different locations, once with --enable-shared and once with
--enable-static, for example? Do we have an example of a
small library that
In any case, since I'm one of the upstream maintainers of
the package I'm
packaging, I just changed it so that it will compile both
.o and .static.o
w/ different flags. But I'm still interested in clarifying
your answer.
.static.o is bad because it is not portable to other
There are some strange commercial compilers out there that have this
problem. Since this is the upstream package, not the Debian one, you
cannot assume a certain compiler. Also, two suffixes don't
work with BSD
make.
The library does require gmake :) I guess I could use .ao or whatever.
I don't use libtool because libtool has problems when gcc
is used with the
platform's ld on Solaris for example: static initializers
aren't called.
Does the Solaris runtime linker support that?
It does for CC output, not for gcc. That's the problem. libtool should
recognize that and
Another thing you could do is to stuck the libs in a
subdirectory and have
your postinst and postrm edit /etc/ld.so.conf. That sounds like the
traditional way to me, but then that was before rpath...
It's a little trickier than the way xaw3d handled it though. A
half-dozen packages or
1. I see no mention on rpath in the policy manual (grepping
through all the
.html files) yet lintian issues a warning about it. I'm
asking because I'm
packaging something that uses rpath heavily.
rpath hardcodes an item's location. If this item later
moves, everything using
it
I was wondering about rpath as well. I maintain a couple
packages that drop 5 function libs for regina-rexx in /usr/lib.
There are probably another 6-8 that someone might package.
/usr/lib could soon be as bad as /var/lib/dpkg/info. You can
pretty much go for coffee on your first 'dpkg -S'.
Hi,
I was browsing policy to familiarize myself with it again, and I have two
questions:
1. I see no mention on rpath in the policy manual (grepping through all the
.html files) yet lintian issues a warning about it. I'm asking because I'm
packaging something that uses rpath heavily.
2. The
I am sure it's an FAQ, sorry... I am making a package with a library package
and a development package. I started with debhelper. My debian/postinst and
debian/postrm call ldconfig. Now what happens is that they end up in my
libxxx-dev package, not my libxxx1 one (which is populated using
I am sure it's an FAQ, sorry... I am making a package with a library package
and a development package. I started with debhelper. My debian/postinst and
debian/postrm call ldconfig. Now what happens is that they end up in my
libxxx-dev package, not my libxxx1 one (which is populated using
Hi,
I've been away from the Debian project for a couple years, but I'm now able
to come back and start packaging things again. I wonder if there is still a
size limit on packages? I want to package the ICU Unicode and I18N library,
and the resulting package right now is ~3.6 Mb. is that
Hi,
I've been away from the Debian project for a couple years, but I'm now able
to come back and start packaging things again. I wonder if there is still a
size limit on packages? I want to package the ICU Unicode and I18N library,
and the resulting package right now is ~3.6 Mb. is that
considering we have packages like mozilla which top 10mb
Ugh! Dinosaurs are heavy, aren't they?
That said, if all of the contents are not useful to
all people, perhaps
it should be split. Every time this package is updated, its
users must
download 4mb's.
I know that. I'm working with
58 matches
Mail list logo
