making source compile

1998-04-17 Thread Jeff Shilt
  I'm working on packaging FPK-pascal and have run into a problem
compiling the source (although it had worked a few times before).  The
source builds a library, libfpc.so, and uses this later to make the
binaries. However, it can no longer find this library when it gets to
compiling the binaries.
  I have the binaries that I downloaded since it's written in pascal so
uses itself to compile and libfpc didn't come with it, although it's
basically a library of units so it might just have the units seperately.
  I have tried changing options in the makefiles and none have worked so
far. I have also deleted all the source and started over from the original.
I've posted on the fpk mailing list and am waiting to hear from them.

  What I'm wondering is if it's allowable to move this lib into /usr/lib
at the approriate time in the makefile so it can be found later.  The
install puts this there later anyway.

Thanks
  Jef


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]


Re: One source, two binary packages

1998-04-17 Thread Karl M. Hegbloom
 Santiago == Santiago Vila [EMAIL PROTECTED] writes:

Santiago Currently, you force to have those tools installed to
Santiago everybody who wants to recompile the package.

 Why is it a problem to require that `autoconf' and `automake' be
installed?  Once you install the compiler, make, and the library -dev
packages, why not just install the auto* programs too, to complete the
system?


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]


Re: Lib packaging question

1998-04-17 Thread Karl M. Hegbloom
 shaleh == shaleh  [EMAIL PROTECTED] writes:

shaleh When creating lib packages, which package should link
shaleh libfoo.so.?.? to libfoo.so??  Should the -dev or the lib
shaleh itself??

 The lib itself.

 libfoo.so.1.2.3
 libfoo.so - libfoo.so.1.2.3
 libfoo.so.1 - libfoo.so.1.2.3

 postinst:
  ldconfig

 postrm:
  ldconfig

  You can gather a lot of info from the files in /var/lib/dpkg/info.
It's nice to have it all out in the open in a directory of files like
that.  No special tools (other than dired or `mc'), are required to
see what other packages do and where they put files.  I like to use
`dired' and `igrep', in XEmacs.  It's easy to answer a question by
searching.  :-)


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]


Re: closing old bugs

1998-04-17 Thread Karl M. Hegbloom
 Damjan == Damjan Marion [EMAIL PROTECTED] writes:

Damjan   Can someone tell me what I must do to close old bugs,
Damjan after uploading new upstream version. I am a new
Damjan maintainer of that package.

 There's a WWW page up, if you follow the link to the bug tracking
system, from the Debian GNU/Linux home pate at
URL:http://www.debian.org.  You can web link to the instructions and
read, or find out how to have them mailed to you by the bug system.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]


Re: One source, two binary packages

1998-04-17 Thread storm
On 16 Apr 1998, Karl M. Hegbloom wrote:

  Santiago == Santiago Vila [EMAIL PROTECTED] writes:
 
 Santiago Currently, you force to have those tools installed to
 Santiago everybody who wants to recompile the package.
 
  Why is it a problem to require that `autoconf' and `automake' be
 installed?  Once you install the compiler, make, and the library -dev
 packages, why not just install the auto* programs too, to complete the
 system?

It makes the build environment dependant on an unnecessary tool.
Automake, autoconf, libtool, and gettext are all designed specifically so
they aren't required to rebuild sources using them.  Automake changes
reasonably frequently (as does libtool) and you can't be sure to get the
same version of the tool that you used.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]


Config file format [may] change

1998-04-17 Thread Turbo Fredriksson
One of the config files for my package (I'm also the
author of this) may change... I'm planing on a rewrite/
cleanup...

How to I 'force' a user to install the new one, when
they upgrade? I'm thinking about dpkg's 'Okay to install
new version (N is usually ok)' or what ever it exactly
say...

-- 
---
 Turbo  ___ Debian GNU/Linux   Unix _IS_ user friendly - it's just
 ^  ___  /___(_)__  _  __  selective about who its friends are
__  / __  /__  __ \  / / /_  |/_/
  _ /// _  /___  / _  / / / /_/ /__ Turbo Fredriksson Tel: +46-704-697645
  \\\/  /_/_/  /_/ /_/\__,_/ /_/|_|   S-415 10 Göteborg[EMAIL PROTECTED]
  PGP#788CD1A9SWEDEN www5.tripnet.se/~turbo
--- PGP:  B7 92 93 0E 06 94 D6 22  98 1F 0B 5B FE 33 A1 0B 
--
AK-47 Cocaine bomb cryptographic [Hello to all my fans in domestic
surveillance] Noriega Ft. Bragg Ortega World Trade Center munitions
domestic disruption cracking Serbian nuclear counter-intelligence


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]


Re: build bug or change?

1998-04-17 Thread Santiago Vila
-BEGIN PGP SIGNED MESSAGE-

On Wed, 8 Apr 1998, Michael Borella wrote:

 This worked.  Great.  But isn't this an ugly fix?  Perhaps
 there is a problem with debstd.

If you think it is a problem with debstd, please investigate and submit 
a bug against debmake.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNTdFlSqK7IlOjMLFAQEBwQP/XlCTvHCfeGfWC5tCh/PQ42AfoXN0a/FY
x3n25suGv2F9wAxVsxIpGSgV4Tu2cOre/XG5eug78/8wGJpHpoNA230bhqVfh1dA
SdjyfvUHa0mqSBElyZAUW2pQWskSlxdCrBDIIJDcI/0dZt8+k+t/KMV4VWlP0Y7O
LG+kQW+7/fo=
=KnRU
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]


Re: Config file format [may] change

1998-04-17 Thread James LewisMoss
 On 17 Apr 1998 07:55:24 +0200, Turbo Fredriksson [EMAIL PROTECTED] said:

 Turbo One of the config files for my package (I'm also the author of
 Turbo this) may change... I'm planing on a rewrite/ cleanup...

 Turbo How to I 'force' a user to install the new one, when they
 Turbo upgrade? I'm thinking about dpkg's 'Okay to install new
 Turbo version (N is usually ok)' or what ever it exactly say...

I'd check in the postinst to see whether it was upgraded, and if not
upgrade it there.  It should leave a config file.dpkg-dist file
sitting there if they didn't upgrade.  Check for that and copy it over 
the config file if necessary (of course make sure that any changes
to config file get copied into the new file.  Else why would they
have not wanted config file to be overwritten).

(Someone correct me if this isn't possible.)

Or you can do like sysvinit and pop up a message in preinst that says
something like 'If you don't allow the system to upgrade your config
file things will break since the format of the config file has
file changed.  Please say Yes if it asks you whether to upgrade.'

Dres
-- 
@James LewisMoss [EMAIL PROTECTED] |  Blessed Be!
@http://www.dimensional.com/~dres   |  Linux is kewl!
@Argue for your limitations and sure enough, they're yours. Bach


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]


Re: Lib packaging question

1998-04-17 Thread Karl M. Hegbloom
 Karl == Karl M Hegbloom [EMAIL PROTECTED] writes:

 shaleh == shaleh  [EMAIL PROTECTED] writes:
shaleh When creating lib packages, which package should link
shaleh libfoo.so.?.? to libfoo.so??  Should the -dev or the lib
shaleh itself??

Karl  postrm: ldconfig

 This is apparently wrong; `lintian' prints a W for it.  Why?


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]


Re: Lib packaging question

1998-04-17 Thread Adam P. Harris

[EMAIL PROTECTED] (Karl M. Hegbloom) writes:
  shaleh == shaleh  [EMAIL PROTECTED] writes:
 shaleh When creating lib packages, which package should link
 shaleh libfoo.so.?.? to libfoo.so??  Should the -dev or the lib
 shaleh itself??
 
  The lib itself.

Nope.  Please get the latest and greatest Packaging Manual (2.4.1.0)
and read Section 12.

  postinst:
   ldconfig

Nope.

  postrm:
   ldconfig

Nope.

 It's easy to answer a question by searching.

Better to answer your question by reading the manuals.

I'm going to suppress my urge to give the right answers because then
you might not bother actually RTM'ing.

.A. P. [EMAIL PROTECTED]URL:http://www.onShore.com/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]


Re: Lib packaging question

1998-04-17 Thread James Troup
[EMAIL PROTECTED] (Adam P. Harris) writes:

   postinst:
ldconfig
 
 Nope.

Bzzt, wrong answer, you lose, humans die.

RTFM (the latest versions, still in Incoming).  The packaging manual
got this wrong for a long time, and the issue wasn't helped by people
spreading FUD about it.
 
-- 
James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]