Re: packaging question regarding the watch file

[Herminio Hernandez Jr.]

Like I said I am probably over thinking.  

Sent from my iPhone

> On Dec 11, 2016, at 4:00 AM, Andrey Rahmatullin  wrote:
> 
> On Sun, Dec 11, 2016 at 01:24:26AM -0700, Herminio Hernandez Jr wrote:
 Let me try to clarify. Did my package use the code from upstream or the
 code from the watch file to build.
>>> 
>>> Please read how gbp works.
>>> gbp uses the version from d/changelog to find the upstream tag which it
>>> then uses to recreate the orig tarball.
>> 
>> 
>> I have been reading the documentation 
>> here:http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM.GIT.NOTARBALL[1]
>>  
> That says the same thing as I did: "version will be replaced with the
> upstream version number as determined from debian/changelog".
> 
> 
> -- 
> WBR, wRAR

Re: packaging question regarding the watch file

[Andrey Rahmatullin]

On Sun, Dec 11, 2016 at 01:24:26AM -0700, Herminio Hernandez Jr wrote:
> > > Let me try to clarify. Did my package use the code from upstream or the
> > > code from the watch file to build.
> > 
> > Please read how gbp works.
> > gbp uses the version from d/changelog to find the upstream tag which it
> > then uses to recreate the orig tarball.
> 
> 
> I have been reading the documentation 
> here:http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM.GIT.NOTARBALL[1]
>  
That says the same thing as I did: "version will be replaced with the
upstream version number as determined from debian/changelog".


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: packaging question regarding the watch file

[Herminio Hernandez Jr]

On Sunday, December 11, 2016 1:20:05 PM MST Andrey Rahmatullin wrote:
> On Sun, Dec 11, 2016 at 01:16:21AM -0700, Herminio Hernandez Jr wrote:
> > Let me try to clarify. Did my package use the code from upstream or the
> > code from the watch file to build.
> 
> Please read how gbp works.
> gbp uses the version from d/changelog to find the upstream tag which it
> then uses to recreate the orig tarball.


I have been reading the documentation 
here:http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM.GIT.NOTARBALL[1]
 

Just what I saw threw me off I am probably reading too much into it.



[1] http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/
gbp.import.html#GBP.IMPORT.UPSTREAM.GIT.NOTARBALL


signature.asc
Description: This is a digitally signed message part.

Re: packaging question regarding the watch file

[Andrey Rahmatullin]

On Sun, Dec 11, 2016 at 01:16:21AM -0700, Herminio Hernandez Jr wrote:
> Let me try to clarify. Did my package use the code from upstream or the code 
> from the watch file to build.
Please read how gbp works.
gbp uses the version from d/changelog to find the upstream tag which it
then uses to recreate the orig tarball.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: packaging question regarding the watch file

[Herminio Hernandez Jr]

On Sunday, December 11, 2016 12:57:40 PM MST Andrey Rahmatullin wrote:
> On Sat, Dec 10, 2016 at 11:04:30PM -0700, Herminio Hernandez Jr wrote:
> > I have a question regarding packaging using git and the watch file in the
> > Debian directory. There is an open bug 794438 for the KDE Partition
> > Manager. The current package is broken in Sid. In the thread it was
> > mentioned that the KDE Neon has a working package. When I pulled the git
> > repo it was only the Debian directory. So what I was following [1]the
> > git-buildpackage manual  I cloned the partition manager git repo added
> > the debian directory and was able to build a working package. However
> > after looking closely I begun to wonder if I understood what I was doing.
> > So the upstream repro appears to be on version 2.9.90 and preparing to go
> > to version 3.0. However the version that I built was 1.0.3. I did not
> > understand how this could have happened. Then looking in the Debian
> > directory I saw that the watch file is referencing a Source Forge repo
> > with the v1.0.3 tar ball. So my question is when I built the package did
> > I need to pull code from the upstream repo? Did the build tools just pull
> > the tar file down from sf and used it instead? Any help understanding
> > will be appreciated[2]
> I didn't fully understand what are you asking but if you are asking why
> did your package use the 1.0.3 version it's because the package version in
> debian/changelog is 1.0.3.

Let me try to clarify. Did my package use the code from upstream or the code 
from the watch file to build.


signature.asc
Description: This is a digitally signed message part.

Re: packaging question regarding the watch file

[Andrey Rahmatullin]

On Sat, Dec 10, 2016 at 11:04:30PM -0700, Herminio Hernandez Jr wrote:
> I have a question regarding packaging using git and the watch file in the 
> Debian directory. There is an open bug 794438 for the KDE Partition Manager. 
> The current package is broken in Sid. In the thread it was mentioned that the 
> KDE Neon has a working package. When I pulled the git repo it was only the 
> Debian directory. So what I was following [1]the git-buildpackage manual  I 
> cloned the partition manager git repo added the debian directory and was able 
> to build a working package. However after looking closely I begun to wonder 
> if I understood what I was doing. So the upstream repro appears to be on 
> version 2.9.90 and preparing to go to version 3.0. However the version that I 
> built was 1.0.3. I did not understand how this could have happened. Then 
> looking in the Debian directory I saw that the watch file is referencing a 
> Source Forge repo with the v1.0.3 tar ball. So my question is when I built 
> the package did I need to pull code from the upstream repo? Did the build 
> tools just pull the tar file down from sf and used it instead? Any help 
> understanding will be appreciated[2]
I didn't fully understand what are you asking but if you are asking why
did your package use the 1.0.3 version it's because the package version in
debian/changelog is 1.0.3.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

packaging question regarding the watch file

[Herminio Hernandez Jr]

Dear Mentors,

I have a question regarding packaging using git and the watch file in the 
Debian directory. There is an open bug 794438 for the KDE Partition Manager. 
The current package is broken in Sid. In the thread it was mentioned that the 
KDE Neon has a working package. When I pulled the git repo it was only the 
Debian directory. So what I was following [1]the git-buildpackage manual  I 
cloned the partition manager git repo added the debian directory and was able 
to build a working package. However after looking closely I begun to wonder if 
I understood what I was doing. So the upstream repro appears to be on version 
2.9.90 and preparing to go to version 3.0. However the version that I built was 
1.0.3. I did not understand how this could have happened. Then looking in the 
Debian directory I saw that the watch file is referencing a Source Forge repo 
with the v1.0.3 tar ball. So my question is when I built the package did I need 
to pull code from the upstream repo? Did the build tools just pull the tar file 
down from sf and used it instead? Any help understanding will be appreciated[2]

Thanks   
Herminio


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794438
[2] 
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM-GIT


signature.asc
Description: This is a digitally signed message part.

Shared library packaging question

[Wuttke, Joachim]

Dear specialists,

I need more help.  Specifically, I am going to ask 3 questions.

My debian directory is still messed up, as it has been from the beginning:
either the automatic scripts are not ready to assist in generating a 
shared-library
package, or I used them in wrong way.

Here my control file :

---
Source: lmfit
Priority: extra
Maintainer: Joachim Wuttke j.wut...@fz-juelich.de
Build-Depends: debhelper (= 7), autotools-dev
Standards-Version: 3.8.4
Section: libs
Homepage: http://messen-und-deuten.de/lmfit/lmfit.html

Package: lmfit-dev
Section: libdevel
Architecture: any
Depends: lmfit (= ${binary:Version}), ${misc:Depends}
Description: Development files for Levenberg-Marquardt library lmfit
 A self-contained implementation of the Levenberg-Marquardt algorithm.
 Routine lmmin determines a parameter vector p that minimizes the Euclidean
 norm of a vectorial function v(p). The most important application is curve
 fitting: to approximate data y(t) by a function f(t;p), routine lmfit
 minimizes the norm of the residual vector v = y(t) - f(t;p).
 .
 This package contains the include file lmmin.h and some application examples.

Package: lmfit3
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Least-squares minimization and curve fitting
 A self-contained implementation of the Levenberg-Marquardt algorithm.
 Routine lmmin determines a parameter vector p that minimizes the Euclidean
 norm of a vectorial function v(p). The most important application is curve
 fitting: to approximate data y(t) by a function f(t;p), routine lmfit
 minimizes the norm of the residual vector v = y(t) - f(t;p).
 .
 This package contains the shared library and the man page lmfit(3).
---

Stanislav suggested I create an additional doc package. Given the small
size of the entire project, I tend to think it's better not to inflate the 
packaging
overhead and to leave the examples in the dev package.

Question 1:
Is that permissible, or absolutely forbidden by some rule ?

Stanislav suggested the package name lmfit0. By now, however,
I succeeded in instructing autotools to generate the correct shared
library version number so.3.0.2; therefore, it's lmfit3.

Now I need to hand-edit the install files.

Seems straightforward for lmfit3.install:

---
usr/lib/lib*.a
usr/lib/lib*.so
usr/lib/*.la
---

Less trivially, lmfit-dev.install should install the following:

lib/lmmin.h   to   prefix/include/lmmin.h
doc/lmfit.3   to   prefix/share/man/man3
demo/*   to   ?

Question 2:
Where should the demo sources be installed to ?

Question 3:
Is it possible to write an install file such that the source directory
(e.g. lib) is different from the destination directory (include) ?
Or do I need to first reorganize my source directories ?

Thanks in advance, Joachim



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt




--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/eecf718003702b4f89104e3dbaa0ad030f93cd6...@mbx-cluster01.ad.fz-juelich.de

RE: Shared library packaging question

[Wuttke, Joachim]

One more question (which possibly elucidates my previous questions):

The upstream project is structured as follows:

lmfit/configure.ac
lmfit/Makefile.am
# ... and all the resulting autotools stuff

lmfit/lib/ # contains library sources and the include file lmmin.h

lmfit/demo/ # contains application examples

So, at present, by running the usual configure; make; make install
sequence, one gets a working library installation plus working demo
executables.

Do I have to break that up before I can properly set up
a shared-library package and a devdoc package ?

What's the easiest way of reorganizing the upstream directory
in a way that is convenient both for Debian packaging and
for conventional tgz distribution ?

- Joachim





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt




--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/eecf718003702b4f89104e3dbaa0ad030f93cd6...@mbx-cluster01.ad.fz-juelich.de

Re: Shared library packaging question

[Stanislav Maslovski]

On Sat, Mar 27, 2010 at 06:35:42PM +0100, Wuttke, Joachim wrote:
 Dear specialists,
 
 I need more help.  Specifically, I am going to ask 3 questions.
 
 My debian directory is still messed up, as it has been from the beginning:
 either the automatic scripts are not ready to assist in generating a 
 shared-library
 package, or I used them in wrong way.
 
 Here my control file :
 
 ---
 Source: lmfit
 Priority: extra
 Maintainer: Joachim Wuttke j.wut...@fz-juelich.de
 Build-Depends: debhelper (= 7), autotools-dev
 Standards-Version: 3.8.4
 Section: libs
 Homepage: http://messen-und-deuten.de/lmfit/lmfit.html
 
 Package: lmfit-dev
 Section: libdevel
 Architecture: any
 Depends: lmfit (= ${binary:Version}), ${misc:Depends}
 Description: Development files for Levenberg-Marquardt library lmfit
  A self-contained implementation of the Levenberg-Marquardt algorithm.
  Routine lmmin determines a parameter vector p that minimizes the Euclidean
  norm of a vectorial function v(p). The most important application is curve
  fitting: to approximate data y(t) by a function f(t;p), routine lmfit
  minimizes the norm of the residual vector v = y(t) - f(t;p).
  .
  This package contains the include file lmmin.h and some application examples.
 
 Package: lmfit3
 Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Least-squares minimization and curve fitting
  A self-contained implementation of the Levenberg-Marquardt algorithm.
  Routine lmmin determines a parameter vector p that minimizes the Euclidean
  norm of a vectorial function v(p). The most important application is curve
  fitting: to approximate data y(t) by a function f(t;p), routine lmfit
  minimizes the norm of the residual vector v = y(t) - f(t;p).
  .
  This package contains the shared library and the man page lmfit(3).
 ---
 
 Stanislav suggested I create an additional doc package. Given the small
 size of the entire project, I tend to think it's better not to inflate the 
 packaging
 overhead and to leave the examples in the dev package.

Technically speaking, the content of *-dev package is needed only for
compilation. Now imagine that your library became so popular that 1000
packages in debian build-depend on it. That means that when
autobuilding them your *-dev package will have to be unpacked,
installed and purged 1000 times for 1000 builds, with all its content.

 Question 1:
 Is that permissible, or absolutely forbidden by some rule ?

No, it is not forbidden by the policy, but it is simply not the best
thing to do, IMO.

 Stanislav suggested the package name lmfit0.

No, I did not suggest _this_ name. Please reread my mail carefully.

 By now, however, I succeeded in instructing autotools to generate the
 correct shared library version number so.3.0.2; therefore, it's
 lmfit3.

But I guess, the name of the file that gets installed into /usr/lib is
still liblmmin.so.X.Y.Z? Then, the name of the package with the
library should start with liblmmin.

Use this command ((C) Steve Langasek) to get the correct name

$ objdump -p liblmmin.so.3.0.2 | \
  sed -n -e's/^[[:space:]]*SONAME[[:space:]]*//p' | \
  sed -e's/\([0-9]\)\.so\./\1-/; s/\.so\.//'

Another comment. There was nothing wrong with SONAME ending in 0,
because SONAME is not something that you change with every version.
(I hope you are not going to do that).

 Now I need to hand-edit the install files.
 
 Seems straightforward for lmfit3.install:
 
 ---
 usr/lib/lib*.a
 usr/lib/lib*.so
 usr/lib/*.la
 ---
 
 Less trivially, lmfit-dev.install should install the following:
 
 lib/lmmin.h   to   prefix/include/lmmin.h

This file should not be a problem, as it is installed to
debian/tmp/usr/include/ by your Makefile at building time.

A line like 

usr/include/*.h

should do the work. Read man dh_install.

 doc/lmfit.3   to   prefix/share/man/man3

This guy belongs to dh_installman. Read man dh_installman.
Add debian/*.manpages. 

 demo/*   to   ?

man dh_installexamples

 Question 2:
 Where should the demo sources be installed to ?

dh_installexamples installs them to /usr/share/doc/pkgname/examples

 Question 3:
 Is it possible to write an install file such that the source directory
 (e.g. lib) is different from the destination directory (include) ?
 Or do I need to first reorganize my source directories ?

You do not need to reorganize that, Debian tools are enough flexible.

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Shared library packaging question

[Stanislav Maslovski]

On Sat, Mar 27, 2010 at 06:57:03PM +0100, Wuttke, Joachim wrote:
 One more question (which possibly elucidates my previous questions):
 
 The upstream project is structured as follows:
 
 lmfit/configure.ac
 lmfit/Makefile.am
 # ... and all the resulting autotools stuff
 
 lmfit/lib/ # contains library sources and the include file lmmin.h
 
 lmfit/demo/ # contains application examples
 
 So, at present, by running the usual configure; make; make install
 sequence, one gets a working library installation plus working demo
 executables.
 
 Do I have to break that up before I can properly set up
 a shared-library package and a devdoc package ?

No. You do not have to do that. 

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100327185003.ga8...@kaiba.homelan

RE: Shared library packaging question

[Wuttke, Joachim]

Thank you, Stanislav, for your helpful explanations.

Regarding the name of the package:
For many years the upstream project has been called lmfit
(since the main application is curve fitting), but the shared
library has been called lmmin.so (since the fundamental
mathematical operation is minimization). This legacy makes
it impossible to follow the most common mechanism
(as the policy manual says) of choosing a package name
that coincides with the library name. Hence the package name
lmfit3. Version 3 as in upstream.

Regarding the dev packages: Of course I will keep the
development files separated from the shared library package.
I just do not want thirdly a doc package; I still tend to pack
the examples into the dev package.

Kind regards, Joachim





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt




--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/eecf718003702b4f89104e3dbaa0ad030f93cd6...@mbx-cluster01.ad.fz-juelich.de

Re: Shared library packaging question

[Stanislav Maslovski]

On Sat, Mar 27, 2010 at 08:24:05PM +0100, Wuttke, Joachim wrote:
 Thank you, Stanislav, for your helpful explanations.
 
 Regarding the name of the package:
 For many years the upstream project has been called lmfit
 (since the main application is curve fitting), but the shared
 library has been called lmmin.so (since the fundamental
 mathematical operation is minimization). This legacy makes
 it impossible to follow the most common mechanism
 (as the policy manual says) of choosing a package name
 that coincides with the library name. Hence the package name
 lmfit3.

Just a couple of last comments:

Many library packages in Debian have names very different from the
names of their upstream's source packages. This is a common case when
one source package generates several binary packages.

 Version 3 as in upstream.

Well, just a few hours ago the upstream had 3 in the version and 0
in SONAME ;) On what I would like to stress is that in normal cases
there is no simple equality between the soname and the version, and
if there is, then

... it is a sign that there is a problem with the versioning scheme.
Scrap it, and bash the upstream with the libtool manual. It is usually
a good sign that either he has not read the manual thoroughly, or he
has not understood it, or both.

(Debian Library Packaging guide)

 Regarding the dev packages: Of course I will keep the
 development files separated from the shared library package.
 I just do not want thirdly a doc package; I still tend to pack
 the examples into the dev package.

You seem to continously misread my mails. I was writing precisely
about unpacking, installing and purging the *-dev package, and not the
main library package (that will be always installed in parallel).

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100327201646.ga10...@kaiba.homelan

Packaging question

[Peter]

If I post this question in the wrong list please tell me where to ask
the question  :)

I created an update package and it install perfectly but for one thing.
If I install an earlier version, my package won't show up as an update.
It's the first time this has happened. I believe I know why it doesn't
but I don't know how to fix it  :)

The old version has a version as 1:2.1.1, my version is a 2.2 but
because of the 1: in front of the earlier version that one seems to be
preferred.

In the debian/control file I added the line:
Replaces: package (  1:2.1.2)
Result was no update

Changed it to:
Replaces: package (  1:2.1.1)
Result was no Update

Changed it to:
Replaces: package ( = 1:2.1.2)
Result was no update

So what do I need to do to make my package be seen as an update?

-- 
Peter van der Does

GPG Key ID: E77E8E98



signature.asc
Description: OpenPGP digital signature

Re: Packaging question

[Raphael Geissert]

On 15/09/2007, Peter [EMAIL PROTECTED] wrote:
 If I post this question in the wrong list please tell me where to ask
 the question  :)


 So what do I need to do to make my package be seen as an update?

First of all, I would ask you why you have 1: in the package version.
Usually that's added because of a reason.



 --
 Peter van der Does

 GPG Key ID: E77E8E98





-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Say NO to Microsoft Office broken standard.
See http://www.noooxml.org/petition


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

Re: Packaging question

[Matthew Palmer]

On Sat, Sep 15, 2007 at 07:20:29PM -0400, Peter wrote:
 If I post this question in the wrong list please tell me where to ask
 the question  :)
 
 I created an update package and it install perfectly but for one thing.
 If I install an earlier version, my package won't show up as an update.
 It's the first time this has happened. I believe I know why it doesn't
 but I don't know how to fix it  :)
 
 The old version has a version as 1:2.1.1, my version is a 2.2 but
 because of the 1: in front of the earlier version that one seems to be
 preferred.
 
 In the debian/control file I added the line:
 Replaces: package (  1:2.1.2)
 Result was no update
 
 Changed it to:
 Replaces: package (  1:2.1.1)
 Result was no Update
 
 Changed it to:
 Replaces: package ( = 1:2.1.2)
 Result was no update
 
 So what do I need to do to make my package be seen as an update?

You need to leave the epoch (the 1:) in the version number of your new
package.  Once an epoch is in place, it can never be removed as long as the
same package exists in the system.

Policy 5.6.12
(http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version)
will give you all the goss.

- Matt


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

Re: Packaging question

[Peter]

Matthew Palmer wrote:
 On Sat, Sep 15, 2007 at 07:20:29PM -0400, Peter wrote:
 If I post this question in the wrong list please tell me where to ask
 the question  :)

 I created an update package and it install perfectly but for one thing.
 If I install an earlier version, my package won't show up as an update.
 It's the first time this has happened. I believe I know why it doesn't
 but I don't know how to fix it  :)

 The old version has a version as 1:2.1.1, my version is a 2.2 but
 because of the 1: in front of the earlier version that one seems to be
 preferred.

 In the debian/control file I added the line:
 Replaces: package (  1:2.1.2)
 Result was no update

 Changed it to:
 Replaces: package (  1:2.1.1)
 Result was no Update

 Changed it to:
 Replaces: package ( = 1:2.1.2)
 Result was no update

 So what do I need to do to make my package be seen as an update?
 
 You need to leave the epoch (the 1:) in the version number of your new
 package.  Once an epoch is in place, it can never be removed as long as the
 same package exists in the system.
 
 Policy 5.6.12
 (http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version)
 will give you all the goss.
 
 - Matt
 
 
OK, I get it. The reason I asked was because in the changelog at one
point they removed the 1: so I thought it was possible but reading your
answer explains it, they also changed the package name when they removed
the 1:

Thanks for the quick answer guys

-- 
Peter van der Does

GPG Key ID: E77E8E98



signature.asc
Description: OpenPGP digital signature

Re: Packaging question

[Francois-Denis Gonthier]

On September 15, 2007 07:20:29 pm Peter wrote:
 If I post this question in the wrong list please tell me where to ask
 the question  :)

 I created an update package and it install perfectly but for one thing.
 If I install an earlier version, my package won't show up as an update.
 It's the first time this has happened. I believe I know why it doesn't
 but I don't know how to fix it  :)

 The old version has a version as 1:2.1.1, my version is a 2.2 but
 because of the 1: in front of the earlier version that one seems to be
 preferred.

 In the debian/control file I added the line:
 Replaces: package (  1:2.1.2)
 Result was no update

 Changed it to:
 Replaces: package (  1:2.1.1)
 Result was no Update

 Changed it to:
 Replaces: package ( = 1:2.1.2)
 Result was no update

 So what do I need to do to make my package be seen as an update?

The 1: is an epoch number, added by the packager to leave behind mistakes 
left in older version number [1].  You have to keep using it if you want 
your new package to be viewed as an update to the previous version.  You then 
need to use version 1:2.2.

Your use of the Replace field is also incorrect.  You don't need it if you 
correctly set the version number of the new package.  See the policy manual 
to understand what Replace really does [2].

[1] http://www.debian.org/doc/debian-policy/ch-binary.html#s-versions
[2] http://www.debian.org/doc/debian-policy/ch-relationships.html



pgp16nOKw80XX.pgp
Description: PGP signature

Re: general packaging question

[Frank Küster]

Ritesh Raj Sarraf [EMAIL PROTECTED] wrote:

 Hi,

 I've package knetstats for Debian.

 Currently I ran dh_make and did the packaging. dh_make created the debian/
 subfolder and I did the necessary changes to build the package. All is fine
 till here.

 My question is:
 Currently knentstats is at version 1.6.1.
 How would I repackage knetstats when version 1.6.2 is released ? If, then, I
 would re-run dh_make, my old settings would be gone because dh_make would
 create a new debian/ subfolder for knetstats 1.6.2. All my changelog details
 would be gone.

 How would I then add entry of the old changelog into the current knetstats
 package i.e. 1.6.2 ?

If the diff.gz contains only files in the debian directory (i.e. your
changes are organized in patches, or you don't have source changes),
then you can simply copy the debian directory to the new source tree and
add a new changelog entry the usual way.  

If you do have changes to the original source tree, I would apply the
diff.gz to it:

mv knetstats_1.6.2.tar.gz knetstats_1.6.2.orig.tar.gz
tar -xzf knetstats_1.6.2.orig.tar.gz
cd knetstats-1.6.1/
zcat ../knetstats_1.6.1-$rev.diff.gz | patch -p1

and then look at the hunks that were rejected.

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: general packaging question

[Bas Wijnen]

On Tue, Nov 14, 2006 at 03:00:40PM +0530, Ritesh Raj Sarraf wrote:
 Hi,

Hello,

 My question is:
 Currently knentstats is at version 1.6.1.
 How would I repackage knetstats when version 1.6.2 is released ?

There are several ways.  Personally, I just get the new upstream tarball,
unpack it, rename things (the tarball and the unpacked directory), and copy
over the debian/ directory from the previous version.  Then I make changes
again.

That method only really works if you have no debian-specific patches outside
debian/.  If you do, you probably want to use uupdate.  That does all the
above for you, except adding the debian directory, plus it applies the
previous version's diff.gz.  So that adds all debian-specific things
(including the debian/ directory).

 If, then, I would re-run dh_make, my old settings would be gone because
 dh_make would create a new debian/ subfolder for knetstats 1.6.2.

If I understood it correctly, dh_make will actually keep your changes (if you
had them in the tree when running it).  I've never used it myself, though.
Packages work fine without rerunning dh_make.

 How would I then add entry of the old changelog into the current knetstats
 package i.e. 1.6.2 ?

When you have the new tree prepared, dch.  The entry is already there, made by
uupdate.

 I hope there is a proper way to tackle such situations.

If there wouldn't, I'm sure someone would have created one real soon. :-)

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://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: general packaging question

[Loïc Minier]

On Tue, Nov 14, 2006, Frank Küster wrote:
  How would I then add entry of the old changelog into the current knetstats
  package i.e. 1.6.2 ?
 If the diff.gz contains only files in the debian directory (i.e. your
 changes are organized in patches, or you don't have source changes),
 then you can simply copy the debian directory to the new source tree and
 add a new changelog entry the usual way.  

 Fortunately, uupdate takes care of this task in both cases.

-- 
Loïc Minier [EMAIL PROTECTED]
10 SIN
20 GO TO ROBOT HELL -- Temple of Robotology


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

Re: general packaging question

[Sune Vuorela]

On 2006-11-14, Ritesh Raj Sarraf [EMAIL PROTECTED] wrote:
 How would I then add entry of the old changelog into the current knetstats
 package i.e. 1.6.2 ?

 I hope there is a proper way to tackle such situations.


apt-get install devscripts
man uupdate

it does exactly what you ask for.

/Sune


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

general packaging question

[Ritesh Raj Sarraf]

Hi,

I've package knetstats for Debian.

Currently I ran dh_make and did the packaging. dh_make created the debian/
subfolder and I did the necessary changes to build the package. All is fine
till here.

My question is:
Currently knentstats is at version 1.6.1.
How would I repackage knetstats when version 1.6.2 is released ? If, then, I
would re-run dh_make, my old settings would be gone because dh_make would
create a new debian/ subfolder for knetstats 1.6.2. All my changelog details
would be gone.

How would I then add entry of the old changelog into the current knetstats
package i.e. 1.6.2 ?

I hope there is a proper way to tackle such situations.

Thanks,
Ritesh
-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
Necessity is the mother of invention.
Stealing logic from one person is plagiarism, stealing from many is research.
The great are those who achieve the impossible, the petty are those who
cannot - rrs


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

n00b lib packaging question

[Jean-Sebastien Pilon]

 
 Hello,

I am trying to create packages from sources for libpcap compiled with
the libpfring library. This compiles no problem. When I am packaging
though... there are the issues coming up Wink

# fakeroot debian/rules clean
# debian/rules build
# debian/rules binary
till now it's ok

i have 2 .debs which contains only the documentation...

so edited debian/rules and uncommented dh_install Wink

after another complete run, still nothing else than the docs in the
packages...


# ls debian/
changelog compat control copyright dirs docs libpcap-ring1.dirs
libpcap-ring1.install libpcap-ring-dev.dirs libpcap-ring-dev.install
rules

so...

# fakeroot debian/rules clean
# debian/rules build
# fakeroot debian/rules install

# ls debian/
changelog control dirs libpcap-ring1 libpcap-ring1.install
libpcap-ring-dev.dirs rules
compat copyright docs libpcap-ring1.dirs libpcap-ring-dev
libpcap-ring-dev.install tmp

3 new folders... tmp libpcap-ring1 libpcap-ring-dev

libpcap-ring1 libpcap-ring-dev -- contains only empty folder structure

# ls debian/libpcap-ring1/ -AR
debian/libpcap-ring1/:
usr

debian/libpcap-ring1/usr:
local

debian/libpcap-ring1/usr/local:
lib

debian/libpcap-ring1/usr/local/lib:

# ls debian/libpcap-ring-dev/ -AR
debian/libpcap-ring-dev/:
usr

debian/libpcap-ring-dev/usr:
local

debian/libpcap-ring-dev/usr/local:
include lib

debian/libpcap-ring-dev/usr/local/include:

debian/libpcap-ring-dev/usr/local/lib:



tmp contains folder structures + expected files...

# ls debian/tmp/ -AR
debian/tmp/:
usr

debian/tmp/usr:
local

debian/tmp/usr/local:
include lib share

debian/tmp/usr/local/include:
pcap-bpf.h pcap.h pcap-namedb.h

debian/tmp/usr/local/lib:
libpcap.a

debian/tmp/usr/local/share:
man

debian/tmp/usr/local/share/man:
man3

debian/tmp/usr/local/share/man/man3:
pcap.3


i guess debian/binary is looking in those 2 directories since it wants
to create 2 packages

am i right? does it make sense? hehe

how can i fix this ?






Thanks,
JS

RE: n00b lib packaging question

[Jean-Sebastien Pilon]

 
 Am Dienstag, den 29.08.2006, 12:44 -0400 schrieb Jean-Sebastien Pilon:
 
  I am trying to create packages from sources for libpcap 
 compiled with
  the libpfring library. This compiles no problem. When I am packaging
  though... there are the issues coming up Wink
  
  # fakeroot debian/rules clean
  # debian/rules build
  # debian/rules binary
  till now it's ok
  
  i have 2 .debs which contains only the documentation...
  
  so edited debian/rules and uncommented dh_install Wink
  
  after another complete run, still nothing else than the docs in the
  packages...
  
  
  # ls debian/
  changelog compat control copyright dirs docs libpcap-ring1.dirs
  libpcap-ring1.install libpcap-ring-dev.dirs libpcap-ring-dev.install
  rules
 [snip]
  3 new folders... tmp libpcap-ring1 libpcap-ring-dev
 [..]
  i guess debian/binary is looking in those 2 directories 
 since it wants
  to create 2 packages
 
 In compat level 4, the files to package are expected in 
 debian/$package.
 
  am i right? does it make sense? hehe
  
  how can i fix this ?
 
 What's inside libpcap-ring1.install and libpcap-ring-dev.install? You
 need to copy the files from debian/tmp to debian/$package 


# cat debian/libpcap-ring1.install
usr/local/lib/lib*.so.*

# cat debian/libpcap-ring-dev.install
usr/local/include/*
usr/local/lib/lib*.a
usr/local/lib/lib*.so
usr/local/lib/pkgconfig/*
usr/local/lib/*.la

Should I normally expect dh_install to put the files at the right place?
Or is it its behavior whan trying to split into 2 packages?


 to split the
 files into separate packages. Normally I would expect at least
 
 debian/tmp/usr/lib/*.so.* usr/lib
 
 for the library- and
 
 debian/tmp/usr/lib/*.la usr/lib
 debian/tmp/usr/lib/*.so usr/lib
 
 for the dev-package. See
 also /usr/share/debhelper/dh_make/debianl/*.install.
 
 Regards, Daniel
 
 
 -- 
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact 
 [EMAIL PROTECTED]
 
 

RE: n00b lib packaging question

[Daniel Leidert]

Am Dienstag, den 29.08.2006, 15:54 -0400 schrieb Jean-Sebastien Pilon:

[..]
  What's inside libpcap-ring1.install and libpcap-ring-dev.install? You
  need to copy the files from debian/tmp to debian/$package 
 
 
 # cat debian/libpcap-ring1.install
 usr/local/lib/lib*.so.*
 
 # cat debian/libpcap-ring-dev.install
 usr/local/include/*
 usr/local/lib/lib*.a
 usr/local/lib/lib*.so
 usr/local/lib/pkgconfig/*
 usr/local/lib/*.la
 
 Should I normally expect dh_install to put the files at the right place?

I guess, you need to add '--sourcedir=debian/tmp' to your dh_install
call in debian/rules. Refer to dh_install's manpage.

Regards, Daniel


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

Packaging question (synopsis and its libraries)

[Andreas Fester]

Hi,

I am currently adopting synopsis, a source code documentation
tool specially suited for python, but also useable for
C and C++. I created a first package from the new upstream
version which is available at http://www.littletux.net/debian.

The package is not yet lintian clean, and this leads to my question:

The package contains some python extension modules written in
C/C++, which all depend on a common library, libSynopsis, which is
also part of the package. By default, libSynopsis is installed below
/usr/lib, but without correct SONAME. So I decided to install
it below some private library directory, BUT this included adding
the private library search path to the python extension modules'
RPATH, which I learned is a Bad Thing(TM) (lintian also tells
me about that). I also do not want to fiddle with /etc/ld.so.conf,
so I think the following possibilities exist:

1) Leave it as it is, and add a lintian override. This might
   be a proper solution, as it seems that rpaths are not regarded
   *that* bad if they point to a non-public lib directory, which
   would be the case here.

2) Add a proper SONAME to the library and install it
   below /usr/lib, from the same binary package.

3) Create separate libsynopsis and libsynopsis-dev packages.
   This would have the advantage that the library can be used
   by other applications as well (which is also the intention
   of the upstream developer, at least in the future). Possible
   issue could be that the API is not that stable yet which might
   result in many SONAME changes.

4) Some great (and simple :-) ) solution which I dont know yet...

Number 3) is currently my preferred solution, IMHO this would end
up with a package layout similar to

- synopsis The main package. Installing this is sufficient to
   use synopsis.

- [optionally: synopsis-doc,
   containing information on how to use synopsis itself.
   Not yet sure about this.]

- libsynopsis  The C++ library.

- libsynopsis-dev  The development files

- libsynopsis-doc  The API documentation

The upstream author argued that these are too many packages, but
IMHO this is the proper solution if the library is packaged
separatly.

Any comments appreciated :-)

Thanks  Best Regards,

Andreas

--
Andreas Fester
mailto:[EMAIL PROTECTED]
WWW: http://www.littletux.net
ICQ: 326674288


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

Re: Packaging question (synopsis and its libraries)

[Justin Pryzby]

See my recent message to -mentors and -devel, Nonpublic shared
libraries.  It sees that rpath could be used here because it is a
private library, not used by other packages.  In the future, if that
changes, it will have to have a soname.  For now, you could also just
install to /usr/lib/libSynopsis.so, without any trailing version
numbers on the filename.

-- 
Clear skies,
Justin

On Thu, Sep 29, 2005 at 09:47:00PM +0200, Andreas Fester wrote:
 Hi,
 
 I am currently adopting synopsis, a source code documentation
 tool specially suited for python, but also useable for
 C and C++. I created a first package from the new upstream
 version which is available at http://www.littletux.net/debian.
 
 The package is not yet lintian clean, and this leads to my question:
 
 The package contains some python extension modules written in
 C/C++, which all depend on a common library, libSynopsis, which is
 also part of the package. By default, libSynopsis is installed below
 /usr/lib, but without correct SONAME. So I decided to install
 it below some private library directory, BUT this included adding
 the private library search path to the python extension modules'
 RPATH, which I learned is a Bad Thing(TM) (lintian also tells
 me about that). I also do not want to fiddle with /etc/ld.so.conf,
 so I think the following possibilities exist:
 
 1) Leave it as it is, and add a lintian override. This might
be a proper solution, as it seems that rpaths are not regarded
*that* bad if they point to a non-public lib directory, which
would be the case here.
 
 2) Add a proper SONAME to the library and install it
below /usr/lib, from the same binary package.
 
 3) Create separate libsynopsis and libsynopsis-dev packages.
This would have the advantage that the library can be used
by other applications as well (which is also the intention
of the upstream developer, at least in the future). Possible
issue could be that the API is not that stable yet which might
result in many SONAME changes.
 
 4) Some great (and simple :-) ) solution which I dont know yet...
 
 Number 3) is currently my preferred solution, IMHO this would end
 up with a package layout similar to
 
 - synopsis The main package. Installing this is sufficient to
use synopsis.
 
 - [optionally: synopsis-doc,
containing information on how to use synopsis itself.
Not yet sure about this.]
 
 - libsynopsis  The C++ library.
 
 - libsynopsis-dev  The development files
 
 - libsynopsis-doc  The API documentation
 
 The upstream author argued that these are too many packages, but
 IMHO this is the proper solution if the library is packaged
 separatly.


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

Debian Packaging Question

[Amr Nasr]

Hi all,
I have upgraded the automake to 1.7.9 and that took care
of some the errors 
but when i try to generate the Makefile through the configure
command it gives me an error saying saying that the script file is not
found which is mainboard.py .
Which i think due to a path that it did not find or one of the
settings related to the source directories and the destination
directories.
 My package is based on a single Python script that i am using.
 Is there any one who can help me on that.
Regards,
Amr

Debian Packaging Question

[Amr Nasr]

hi all ,
I have read the debian Maintainers' Guide for Creating debian Packages
and i was following it for creation of the package and then when i run 
 dh_make according to the instructions i get errors related to
the Makefile that i have
 modified as i am trying to install a script and get it executed
immediately during installation that's why i made the Perl Script
ipcalc executable and also the make file 
and when running that command i get the following errors: 
{
make install DESTDIR=opt/ipcalc/
make[1]: Entering directory
`/home/amr/Projects/Project2-Debian-Packages/Procedure/ipcalc-0.35'
Makefile:18: *** missing separator (did you mean TAB instead of 8
spaces?). Stop.
make[1]: Leaving directory
`/home/amr/Projects/Project2-Debian-Packages/Procedure/ipcalc-0.35'
make: *** [install] Error 2
}

Can anybody help on that by showing me examples of the Makefiles. 
Regards,
Amr 

Re: Debian Packaging Question

[Magnus Therning]

On Thu, Aug 19, 2004 at 12:33:44PM -0600, Amr Nasr wrote:
hi all ,

I have read the debian Maintainers' Guide for Creating debian Packages
and i was following it for creation of the package and then when i run
*dh_make* according to the instructions i get errors related to the
Makefile that i have modified as i am trying to install a script and
get it executed immediately during installation that's why i made the
Perl Script ipcalc executable and also the make file and when running
that command i get the following errors:

{
make install DESTDIR=opt/ipcalc/
make[1]: Entering directory 
`/home/amr/Projects/Project2-Debian-Packages/Procedure/ipcalc-0.35'
Makefile:18: *** missing separator (did you mean TAB instead of 8 
spaces?).  Stop.
make[1]: Leaving directory 
`/home/amr/Projects/Project2-Debian-Packages/Procedure/ipcalc-0.35'
make: *** [install] Error 2
}

make is a little picky about the lines in a makefile. The indentation
should be made using tabs. You seem to have a line that's indented using
spaces... change that and you should be fine.

/M

-- 
Magnus Therning(OpenPGP: 0xAB4DFBA4)
[EMAIL PROTECTED]
http://magnus.therning.org/

The network is a stochastic synchronicity generator.
 -- Christopher Locke


signature.asc
Description: Digital signature

Re: Debian Packaging Question

[Ricardo Mones]

On Thu, 19 Aug 2004 12:33:44 -0600
Amr Nasr [EMAIL PROTECTED] wrote:

 Makefile:18: *** missing separator (did you mean TAB instead of 8 
 spaces?).  Stop.

objective: dependencies
rules

These separators *must* be one tab keypress, not spaces. All of them.
Maybe your editor has converted tabs to spaces when cut'n'pasting.

[...]
 Can anybody help on that by showing me examples of the Makefiles.

  Try: apt-get source x
  Where x is the name of any package you like. I'm sure you'll found some.
-- 
  Ricardo Mones Lastra - [EMAIL PROTECTED]
  Centro de Inteligencia Artificial, Universidad de Oviedo en Gijon
  33271 Asturias, SPAIN. - http://www.aic.uniovi.es/mones


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

Debian Packaging Question

[Amr Nasr]

hi all ,
I have read the debian Maintainers' Guide for Creating debian Packages
and i was following it for creation of the package and then when i run 
 dh_make according to the instructions i get errors related to
the Makefile that i have
 modified as i am trying to install a script and get it executed
immediately during installation that's why i made the Perl Script
ipcalc executable and also the make file 
and when running that command i get the following errors: 
{
make install DESTDIR=opt/ipcalc/
make[1]: Entering directory
`/home/amr/Projects/Project2-Debian-Packages/Procedure/ipcalc-0.35'
Makefile:18: *** missing separator (did you mean TAB instead of 8
spaces?). Stop.
make[1]: Leaving directory
`/home/amr/Projects/Project2-Debian-Packages/Procedure/ipcalc-0.35'
make: *** [install] Error 2
}

Can anybody help on that by showing me examples of the Makefiles. 
Regards,
Amr 

Re: Debian Packaging Question

[Magnus Therning]

On Thu, Aug 19, 2004 at 12:33:44PM -0600, Amr Nasr wrote:
hi all ,

I have read the debian Maintainers' Guide for Creating debian Packages
and i was following it for creation of the package and then when i run
*dh_make* according to the instructions i get errors related to the
Makefile that i have modified as i am trying to install a script and
get it executed immediately during installation that's why i made the
Perl Script ipcalc executable and also the make file and when running
that command i get the following errors:

{
make install DESTDIR=opt/ipcalc/
make[1]: Entering directory 
`/home/amr/Projects/Project2-Debian-Packages/Procedure/ipcalc-0.35'
Makefile:18: *** missing separator (did you mean TAB instead of 8 
spaces?).  Stop.
make[1]: Leaving directory 
`/home/amr/Projects/Project2-Debian-Packages/Procedure/ipcalc-0.35'
make: *** [install] Error 2
}

make is a little picky about the lines in a makefile. The indentation
should be made using tabs. You seem to have a line that's indented using
spaces... change that and you should be fine.

/M

-- 
Magnus Therning(OpenPGP: 0xAB4DFBA4)
[EMAIL PROTECTED]
http://magnus.therning.org/

The network is a stochastic synchronicity generator.
 -- Christopher Locke


signature.asc
Description: Digital signature

Re: Debian Packaging Question

[Ricardo Mones]

On Thu, 19 Aug 2004 12:33:44 -0600
Amr Nasr [EMAIL PROTECTED] wrote:

 Makefile:18: *** missing separator (did you mean TAB instead of 8 
 spaces?).  Stop.

objective: dependencies
rules

These separators *must* be one tab keypress, not spaces. All of them.
Maybe your editor has converted tabs to spaces when cut'n'pasting.

[...]
 Can anybody help on that by showing me examples of the Makefiles.

  Try: apt-get source x
  Where x is the name of any package you like. I'm sure you'll found some.
-- 
  Ricardo Mones Lastra - [EMAIL PROTECTED]
  Centro de Inteligencia Artificial, Universidad de Oviedo en Gijon
  33271 Asturias, SPAIN. - http://www.aic.uniovi.es/mones

Re: simple cron packaging question

[Colin Watson]

On Thu, Aug 05, 2004 at 08:42:50AM -0700, Josh Lauricha wrote:
 On Thu 08/05/04 17:35, Brian Sutherland wrote:
  Make sure that if the package is uninstalled, the cron job is
  disabled?
 
 I'd do something like:
 # a bunch of lines for setting the command-line options or sourceing
 # /etc/default/packagename
 [ -f /usr/lib/package/scriptname ]  /usr/lib/package/scriptname

Be careful about that in 'set -e' mode or if non-zero exit statuses will
be otherwise reported. I often use one of these idioms instead:

  if [ -f /usr/lib/package/scriptname ]; then /usr/lib/package/scriptname; fi

  [ ! -f /usr/lib/package/scriptname ] || /usr/lib/package/scriptname

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]


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

Re: simple cron packaging question

[Colin Watson]

On Thu, Aug 05, 2004 at 08:42:50AM -0700, Josh Lauricha wrote:
 On Thu 08/05/04 17:35, Brian Sutherland wrote:
  Make sure that if the package is uninstalled, the cron job is
  disabled?
 
 I'd do something like:
 # a bunch of lines for setting the command-line options or sourceing
 # /etc/default/packagename
 [ -f /usr/lib/package/scriptname ]  /usr/lib/package/scriptname

Be careful about that in 'set -e' mode or if non-zero exit statuses will
be otherwise reported. I often use one of these idioms instead:

  if [ -f /usr/lib/package/scriptname ]; then /usr/lib/package/scriptname; 
fi

  [ ! -f /usr/lib/package/scriptname ] || /usr/lib/package/scriptname

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

simple cron packaging question

[Brian Sutherland]

As my first foray into debian packaging, I want to create a
package that installs a cron job to be run daily.

My approach is to install a simple script into /etc/cron.daily/
that calls a more complex script which I install into /usr/bin/.

Will this be compliant with the FHS?

Make sure that if the package is uninstalled, the cron job is
disabled?

Thanks,

-- 
Brian Sutherland

There has got to be more to life than just being really,
really, really, ridiculously good-looking. -- Derek Zoolander


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

Re: simple cron packaging question

[Justin Pryzby]

You are correct; see [1].  Make sure it checks for the existence of all
files it needs.

Cheers,
-- 
Justin
aptitude install iraf saods9 eclipse xpa sextractor x11iraf wcstools pyraf
http://www.justinpryzby.com/debian/

References

[1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.5

On Thu, Aug 05, 2004 at 05:35:47PM +0200, Brian Sutherland wrote:
 As my first foray into debian packaging, I want to create a
 package that installs a cron job to be run daily.
 
 My approach is to install a simple script into /etc/cron.daily/
 that calls a more complex script which I install into /usr/bin/.
 
 Will this be compliant with the FHS?
 
 Make sure that if the package is uninstalled, the cron job is
 disabled?
 
 Thanks,
 
 -- 
 Brian Sutherland
 
 There has got to be more to life than just being really,
 really, really, ridiculously good-looking. -- Derek Zoolander
 
 
 -- 
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
 


signature.asc
Description: Digital signature

Re: simple cron packaging question

[Josh Lauricha]

On Thu 08/05/04 17:35, Brian Sutherland wrote:
 As my first foray into debian packaging, I want to create a
 package that installs a cron job to be run daily.
 
 My approach is to install a simple script into /etc/cron.daily/
 that calls a more complex script which I install into /usr/bin/.
 
 Will this be compliant with the FHS?

It should only be under /usr/bin if it is also ment to be used by the
user as well. If not, I think /usr/lib/program/ is where it is
supposed to go.

The FHS can be found at: http://www.pathname.com/fhs/pub/fhs-2.3.html

 Make sure that if the package is uninstalled, the cron job is
 disabled?

I'd do something like:
# a bunch of lines for setting the command-line options or sourceing
# /etc/default/packagename
[ -f /usr/lib/package/scriptname ]  /usr/lib/package/scriptname

as the simple script and make /etc/cron.daily/package a conffile.

But, you might just want to:
$ apt-get source logrotate
to see how the pros do it.

-- 

--
| Josh Lauricha| Ford, you're turning|
| [EMAIL PROTECTED] | into a penguin. Stop|
| Bioinformatics, UCR  | it  |
||
| OpenPG:|
|  4E7D 0FC0 DB6C E91D 4D7B C7F3 9BE9 8740 E4DC 6184 |
||


signature.asc
Description: Digital signature

Re: simple cron packaging question

[Andreas Metzler]

On 2004-08-05 Brian Sutherland [EMAIL PROTECTED] wrote:
 As my first foray into debian packaging, I want to create a
 package that installs a cron job to be run daily.

 My approach is to install a simple script into /etc/cron.daily/
 that calls a more complex script which I install into /usr/bin/.

 Will this be compliant with the FHS?

Why not?

 Make sure that if the package is uninstalled, the cron job is
 disabled?

You have to take care of that yourself, e.g. by starting
/etc/cron.daily/script with
if ! test -x /usr/bin/complexscript ; then
   exit 0
fi

   cu andreas
-- 
See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in Snow Crash


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

Re: simple cron packaging question

[Brian Sutherland]

Im stunned. Three answers in under an hour.

Thanks world.

-- 
Brian Sutherland

There has got to be more to life than just being really,
really, really, ridiculously good-looking. -- Derek Zoolander


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

simple cron packaging question

[Brian Sutherland]

As my first foray into debian packaging, I want to create a
package that installs a cron job to be run daily.

My approach is to install a simple script into /etc/cron.daily/
that calls a more complex script which I install into /usr/bin/.

Will this be compliant with the FHS?

Make sure that if the package is uninstalled, the cron job is
disabled?

Thanks,

-- 
Brian Sutherland

There has got to be more to life than just being really,
really, really, ridiculously good-looking. -- Derek Zoolander

Re: simple cron packaging question

[Justin Pryzby]

You are correct; see [1].  Make sure it checks for the existence of all
files it needs.

Cheers,
-- 
Justin
aptitude install iraf saods9 eclipse xpa sextractor x11iraf wcstools pyraf
http://www.justinpryzby.com/debian/

References

[1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.5

On Thu, Aug 05, 2004 at 05:35:47PM +0200, Brian Sutherland wrote:
 As my first foray into debian packaging, I want to create a
 package that installs a cron job to be run daily.
 
 My approach is to install a simple script into /etc/cron.daily/
 that calls a more complex script which I install into /usr/bin/.
 
 Will this be compliant with the FHS?
 
 Make sure that if the package is uninstalled, the cron job is
 disabled?
 
 Thanks,
 
 -- 
 Brian Sutherland
 
 There has got to be more to life than just being really,
 really, really, ridiculously good-looking. -- Derek Zoolander
 
 
 -- 
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
 


signature.asc
Description: Digital signature

Re: simple cron packaging question

[Josh Lauricha]

On Thu 08/05/04 17:35, Brian Sutherland wrote:
 As my first foray into debian packaging, I want to create a
 package that installs a cron job to be run daily.
 
 My approach is to install a simple script into /etc/cron.daily/
 that calls a more complex script which I install into /usr/bin/.
 
 Will this be compliant with the FHS?

It should only be under /usr/bin if it is also ment to be used by the
user as well. If not, I think /usr/lib/program/ is where it is
supposed to go.

The FHS can be found at: http://www.pathname.com/fhs/pub/fhs-2.3.html

 Make sure that if the package is uninstalled, the cron job is
 disabled?

I'd do something like:
# a bunch of lines for setting the command-line options or sourceing
# /etc/default/packagename
[ -f /usr/lib/package/scriptname ]  /usr/lib/package/scriptname

as the simple script and make /etc/cron.daily/package a conffile.

But, you might just want to:
$ apt-get source logrotate
to see how the pros do it.

-- 

--
| Josh Lauricha| Ford, you're turning|
| [EMAIL PROTECTED] | into a penguin. Stop|
| Bioinformatics, UCR  | it  |
||
| OpenPG:|
|  4E7D 0FC0 DB6C E91D 4D7B C7F3 9BE9 8740 E4DC 6184 |
||


signature.asc
Description: Digital signature

Re: simple cron packaging question

[Andreas Metzler]

On 2004-08-05 Brian Sutherland [EMAIL PROTECTED] wrote:
 As my first foray into debian packaging, I want to create a
 package that installs a cron job to be run daily.

 My approach is to install a simple script into /etc/cron.daily/
 that calls a more complex script which I install into /usr/bin/.

 Will this be compliant with the FHS?

Why not?

 Make sure that if the package is uninstalled, the cron job is
 disabled?

You have to take care of that yourself, e.g. by starting
/etc/cron.daily/script with
if ! test -x /usr/bin/complexscript ; then
   exit 0
fi

   cu andreas
-- 
See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in Snow Crash

Re: simple cron packaging question

[Brian Sutherland]

Im stunned. Three answers in under an hour.

Thanks world.

-- 
Brian Sutherland

There has got to be more to life than just being really,
really, really, ridiculously good-looking. -- Derek Zoolander

Packaging question

[Dan Korostelev]

Is it possible to make some files installed by 'make install' excluded
from deb package???

-- 
Dan Korostelev [EMAIL PROTECTED]

Packaging question

[Dan Korostelev]

Is it possible to make some files installed by 'make install' excluded
from deb package???

-- 
Dan Korostelev [EMAIL PROTECTED]


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

Re: Packaging question

[Laszlo 'GCS' Boszormenyi]

* Dan Korostelev [EMAIL PROTECTED] [2004-06-28 19:41:27 +0400]:

 Is it possible to make some files installed by 'make install' excluded
 from deb package???
 Delete them after 'make install' from debian/rules . You may tamper
with the Makefile as well, but be it as a last resort, only if the 'make
install' create big files/files after a long calculation etc, you got
the idea.

Hope this helps,
Laszlo/GCS


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

Re: Packaging question

[Andreas Metzler]

On Mon, Jun 28, 2004 at 07:41:27PM +0400, Dan Korostelev wrote:
 Is it possible to make some files installed by 'make install' excluded
 from deb package???

Sure.
rm debian/package/blah/fasel
in debian/rules after make install.
cu andreas


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

Re: Packaging question

[Dan Korostelev]

On , 2004-06-28 at 17:48 +0200, Laszlo 'GCS' Boszormenyi wrote:

  Delete them after 'make install' from debian/rules . You may tamper
 with the Makefile as well, but be it as a last resort, only if the 'make
 install' create big files/files after a long calculation etc, you got
 the idea.
Okay understood. I didn't want to alter Makefiles, because my package
installs empty docs files in /usr/doc, but It looks like it's impossible
to build a deb package w/o total Makefile.am  configure.in fixing,
because crappy build environment, generated by some old buggy version
Anjuta. The software is UrlGfe (http://urlget.sf.net). I'm stuck.

-- 
Dan Korostelev [EMAIL PROTECTED]


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

Re: newbie packaging question

[Eric Winger]

Goswin von Brederlow wrote:

Hi,

by the way, do you use debuild to build your package?

I'm using dpkg-buildpackage -rfakeroot

That way Debian will do some more checks before and after build like
build dependencies and lintian runs. Lintian will catch a lot of
little mistakes one can make like having *.ex files still in the
package. Listen to it.
I will look at that as well, thx.

MfG
Goswin


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

Re: newbie packaging question

[Colin Watson]

On Tue, Aug 12, 2003 at 10:38:06AM -0700, Eric Winger wrote:
 Matthew Palmer wrote:
 The easiest way for packages in the actual archive is to run 'apt-get
 source package'.  That'll download the sources and unpack them into
 the current directory.
 
 Ahh, this brings up a point that has bothered me about debian. Well 
 actually in this case, two points.
 
 * all the deb-src entries i tried to add to my sources.list give me 
 errors when I try to get the source. What is the url for sources? This 
 is my latest attempt:
 
 deb-src ftp://ftp.debian.org/debian testing main contrib free

That's correct except that you want non-free there, not free. (Ever
think you'd hear a Debian developer say that?)

 * how can one keep up on what the latest url's are for debian packages 
 etc. Is there a single spot where one can look? Or is this knowledge I 
 will only gain when I use the force?

I found it easiest (years ago) to read the sources.list(5) man page and
learn how those lines map into URLs, so I can then just go off with a
web browser or an FTP client, figure out what URL I need, and construct
the sources.list line from there.

-- 
Colin Watson  [EMAIL PROTECTED]


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

Re: newbie packaging question

[Matthew Palmer]

On Mon, Aug 11, 2003 at 04:16:31PM -0700, Eric Winger wrote:
 thx to all for the responses. I'm slowly making progress here. Could 
 someone distinguish the configuration section and how that applies to 
 debian packages for me (the eternal newbie).

There are several configuration sections you need to take into account. 
They are typically split into package creation, package installation and
runtime configuration.  Package creation config is what's in the debian/
directory of your package source.  Installation time config are known as
maintainer scripts - they consist of the preinst, postinst, prerm, and
postrm scripts run at the appropriate time during configuration, and also
the debconf scripts (which I'm presuming you won't need at this stage).

 I was under the impression that the configuration rules were what the 
 package would run after it was loaded. However, when I did a fakeroot 
 against my simplistic package, it actually ran the config rules which 
 surprised me.

Did a fakeroot as 'in ran fakeroot debian/rules in your package source
directory'?  Then the config files you're talking about are probably
debian/rules and friends.

 Can someone clarify. I'm looking to create the simple .deb package, then 
 put in a 'post load' method which runs the binary i'm putting in the 
 package.

At installation time?  You'll want to add an appropriate command to the
postinst script.  That file gets run after the package's files are unpacked
into their respective locations in the filesystem.

 Also (really really stupid question).. where do i get these sources for 
 the packages you guys mentioned?

The easiest way for packages in the actual archive is to run 'apt-get source
package'.  That'll download the sources and unpack them into the current
directory.

- Matt


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

Re: newbie packaging question

[Eric Winger]

Colin Watson wrote:

That's correct except that you want non-free there, not free. 
(Ever think you'd hear a Debian developer say that?)

would it be sacreligious to ask why sources are kept in non-free?

I found it easiest (years ago) to read the sources.list(5) man page and
learn how those lines map into URLs, so I can then just go off with a
web browser or an FTP client, figure out what URL I need, and construct
the sources.list line from there.
will go reread that. I had only skimmed it before.

thx

am slowly starting to begin to see a glimpse of the light of comprehension.

eric

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



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

Re: newbie packaging question

[Eric Winger]

should have added that I also tried the fakeroot /debian/rules binary to 
build the .deb, but it just told me that it didn't find a file on a line 
that didn't exist in my /rules file.

eric

Winger, Eric wrote:

thx to all for the responses. I'm slowly making progress here. Could
someone distinguish the configuration section and how that applies to
debian packages for me (the eternal newbie).
I was under the impression that the configuration rules were what the
package would run after it was loaded. However, when I did a fakeroot
against my simplistic package, it actually ran the config rules which
surprised me.
Can someone clarify. I'm looking to create the simple .deb package, then
put in a 'post load' method which runs the binary i'm putting in the
package.
Also (really really stupid question).. where do i get these sources for
the packages you guys mentioned?
Eric

Bernhard R. Link wrote:

 * Eric Winger [EMAIL PROTECTED] [030807 21:54]:
  But in following the instructions in the doc it tells me to create 
some
  directories with my source in them, then use dh-make first. But 
dh_make
  keeps telling me it can't find my source package.

 dh_make is optimized to create source packages that automatically 
create
 the binary package. While it is an also be a nice (though not the
 easiest) way to create a .deb out of some upstream binaries, you have
 to understand debhelper a bit more than when using it for waht it was
 made.
 The easiest way is to start with an empty source, i.e. create an
 emtpy directory containing a version number, like
 mkdir blafasel-1.0
 cd blafasel-1.0
 dh_make -n -s -e [EMAIL PROTECTED]

 which should create a debian/-subdirectory with everything needed in 
it.
 In debian/rules just remove the calls to make, and you can already
 create an (almost) empty .deb, by calling fakeroot ./debian/rules.
 (or dpkg-buildpackage -rfakeroot -B, if you prefer this).
 Then just add the proper commands in debian/rules to get the programs
 installed to debian/tmp or debian/name depending on what DH_COMPAT
 you have set and remove those files in debian/ you do not need, and
 perhaps adopting the control and changelog (and the copyright-file
 as it will contain GPL by default) would be a nice idea.

 Hochachtungsvoll,
   Bernhard R. Link

 --
 Sendmail is like emacs: A nice operating system, but missing
 an editor and a MTA.


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



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

Re: newbie packaging question

[David Z Maze]

Eric Winger [EMAIL PROTECTED] writes:

 Ahh, this brings up a point that has bothered me about debian. Well
 actually in this case, two points.

 * all the deb-src entries i tried to add to my sources.list give me
 * errors when I try to get the source. What is the url for sources? 
 * This is my latest attempt:

 deb-src ftp://ftp.debian.org/debian testing main contrib free

That should work fine (well, modulo 'free' not existing; do you mean
'non-free'?).  Have you run 'apt-get update' (or a dselect or
atptitude update) before trying to run 'apt-get source'?  What errors
do you get?

 * how can one keep up on what the latest url's are for debian packages
 * etc. Is there a single spot where one can look? Or is this knowledge
 * I will only gain when I use the force?

It's in the Packages file that 'apt-get update' and friends download.
You can also look on http://packages.debian.org/, or in
debian/pool/main/l/lm-sensors (where lm-sensors is the source package
name, 'l' is its first letter, and library source packages begin with
'libl' or whatever) on your favorite Debian mirror.

-- 
David Maze [EMAIL PROTECTED]  http://people.debian.org/~dmaze/
Theoretical politics is interesting.  Politicking should be illegal.
-- Abra Mitchell


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

Re: newbie packaging question

[Colin Watson]

On Tue, Aug 12, 2003 at 11:53:27AM -0700, Eric Winger wrote:
 Colin Watson wrote:
 That's correct except that you want non-free there, not free. 
 (Ever think you'd hear a Debian developer say that?)
 
 would it be sacreligious to ask why sources are kept in non-free?

I think one of us is confused. :) Source for non-free packages is in
non-free, but if you aren't interested in that or would rather avoid it
you're of course entirely welcome to omit the non-free word from that
line.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]


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

Re: newbie packaging question

[Eric Winger]

Matthew Palmer wrote:

The easiest way for packages in the actual archive is to run 'apt-get 
source
package'.  That'll download the sources and unpack them into the 
current
directory.

Ahh, this brings up a point that has bothered me about debian. Well 
actually in this case, two points.

* all the deb-src entries i tried to add to my sources.list give me 
errors when I try to get the source. What is the url for sources? This 
is my latest attempt:

deb-src ftp://ftp.debian.org/debian testing main contrib free

also tried woody, main, etc.

* how can one keep up on what the latest url's are for debian packages 
etc. Is there a single spot where one can look? Or is this knowledge I 
will only gain when I use the force?

thx

eric

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

Re: newbie packaging question

[Joshua Kwan]

On Tue, Aug 12, 2003 at 04:40:42PM -0700, Eric Winger wrote:
 Any ideas? Or is the postinst.ex file correct, and i may be not writing 
 the script correctly. I just added:
 
 cp myFile /hardcoded path/
 ./path/myFile (wishing to run that file)

.ex stands for example. remove the .ex.

I suggest that instead of using newmaint as your bible, source a few
simple packages and look at how they do things.

--
Joshua Kwan


pgp0.pgp
Description: PGP signature

Re: newbie packaging question

[Eric Winger]

ok, I've managed to make a .deb file  a big ol tarball. Questions:

* I would like to test install this package but not go through the 
apt-get stuff, because i believe it goes to sources.list etc. Is there a 
simple way to simulate this load to see if my commands run successfully? 
Or even load the .deb file directly? The deb maintainers guide doesn't 
seem to speak to this (or i'm missing this)

* I thought that the .deb file would end up containing all of my files, 
but the only thing that could possible hold my source is the big tarball 
that dpkg-buildpackage built for me. Does this seem correct?

thx,

Eric

Matthew Palmer wrote:

On Mon, Aug 11, 2003 at 04:16:31PM -0700, Eric Winger wrote:
 thx to all for the responses. I'm slowly making progress here. Could
 someone distinguish the configuration section and how that applies to
 debian packages for me (the eternal newbie).
There are several configuration sections you need to take into account.
They are typically split into package creation, package 
installation and
runtime configuration.  Package creation config is what's in the 
debian/
directory of your package source.  Installation time config are 
known as
maintainer scripts - they consist of the preinst, postinst, prerm, and
postrm scripts run at the appropriate time during configuration, and also
the debconf scripts (which I'm presuming you won't need at this stage).

 I was under the impression that the configuration rules were what the
 package would run after it was loaded. However, when I did a fakeroot
 against my simplistic package, it actually ran the config rules which
 surprised me.
Did a fakeroot as 'in ran fakeroot debian/rules in your package 
source
directory'?  Then the config files you're talking about are probably
debian/rules and friends.

 Can someone clarify. I'm looking to create the simple .deb package, 
then
 put in a 'post load' method which runs the binary i'm putting in the
 package.

At installation time?  You'll want to add an appropriate command to the
postinst script.  That file gets run after the package's files are 
unpacked
into their respective locations in the filesystem.

 Also (really really stupid question).. where do i get these sources for
 the packages you guys mentioned?
The easiest way for packages in the actual archive is to run 'apt-get 
source
package'.  That'll download the sources and unpack them into the 
current
directory.

- Matt

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



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

Re: newbie packaging question

[Eric Winger]

I've been able to build a package, install it, get a postinst script to 
run properly. Now, I'm at the point in my little test where 
understanding where everything goes during install is important.

I'm moving away from using New Deb Maintainer docs and trying to follow 
advice given in this forum, and looking at simple packages and how they 
do things. In particular, I'm trying to figure out why phtml copies 
files during the build process. That doesn't make sense to me because it 
seems like one could put those in the proper directory before the 
package build.

So to simplify the questions:
* why does phtml do a copy in the rules file install step?
* what links are available to start to explain where things should go  
do go during the install process?
* what would be the (current directory) during an apt-get install?

I suspect there are links to this general type of question already.  In 
the meantime, Ill keep browsing the docs I have. Hopefully, the kind of 
questions I'm working on are clear. Because they effect things like 
purge  remove steps too.

thx

Eric

Matthew Palmer wrote:

On Thu, Aug 07, 2003 at 12:54:08PM -0700, Eric Winger wrote:
 I hope that I've selected the correct debian mailing list for this
 question. But if not, I would appreciate if you could redirect 
properly.

Nope, this is the right spot.

 My first steps are proving to be quite haltingly slow. I'm the Debian
 New Maintainer's Guide and I've setup a simple goal for myself. To take
 an installation .bin (known to work) and make a debian package out of
 it. No sources, just a .bin. Then debian, upon installing this package,
 would simply run a little config script to run the .bin file.
Ayup.  Quite simple.

 But in following the instructions in the doc it tells me to create some
 directories with my source in them, then use dh-make first. But dh_make
 keeps telling me it can't find my source package.
That would be the tarball containing the source for your package.  The
source is simply whatever gets released without debian 
modifications.  Of
course, there are debian native packages, where the source and 
debian bits
are all together.

The things which absolutely have to be in a package in order to be 
built are
debian/rules and debian/control.  debian/rules gives the commands 
required
to make the package, and debian/control has the information necessary to
name the binary packages, dependencies, and the rest.

Your best bet is to get the source for a really simple, debian-native,
architecture-independent package, and change the small bit of code 
that has
to be changed to copy your binary to the right place.

Executing commands after installation can be done in the postinst file,
which is usually just a shell script.  Adding a startup script can be 
done
with dh_installinit (see the manpage).

An example of a simple package as described above is phtml.  (Mandatory
disclosure: I maintain it).
 So two questions, does the source package need to be raw code or is it
 specific term to refer to a C source filled directory? And two, is my
 goal reasonable for a first-timer?
Your goal is reasonable, and no, source code doesn't have to be C 
source
or anything like that.  Consider doc-rfc, or Perl script packages.

- Matt

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



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

Re: newbie packaging question

[Bob Proulx]

Eric Winger wrote:
 would it be sacreligious to ask why sources are kept in non-free?

You are asking an obvious question and the answer is the obvious one.
The sources are in non-free because they are not free.  Look at the
copyrights of any of the packages in non-free and you will see that
they all have some type of restriction.

Bob


pgp0.pgp
Description: PGP signature

Re: newbie packaging question

[Keegan Quinn]

On Tue, Aug 12, 2003 at 04:40:42PM -0700, Eric Winger wrote:
 I've modified the postinst.ex file, but my commands aren't being 
 executed. And the Debian New Maintainers' Guide says I shouldn't do this 
 (add to maintainer scripts) yet. So that tells me I should be putting my 
 configuration commands for the just installed package somewhere else.

You need to rename postinst.ex to just postinst, I think.

 - Keegan


pgp0.pgp
Description: PGP signature

Re: newbie packaging question

[Eric Winger]

Ok, I've managed to create a .deb package, experimented with putting 
things in the rules file, installed my package locally. Learned a little 
about purge and kind of have the gist of what y'all have been trying to 
pound into my head.

But now I've run into a problem. For my first package, which is nothing 
but a test. I want to be able to run some commands after my package has 
been installed. Simple copy  execute commands.

I've modified the postinst.ex file, but my commands aren't being 
executed. And the Debian New Maintainers' Guide says I shouldn't do this 
(add to maintainer scripts) yet. So that tells me I should be putting my 
configuration commands for the just installed package somewhere else.

Any ideas? Or is the postinst.ex file correct, and i may be not writing 
the script correctly. I just added:

cp myFile /hardcoded path/
./path/myFile (wishing to run that file)
thx

Eric

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

Re: newbie packaging question (I get it!)

[Eric Winger]

Ok, I got a few more things understood including what directories get 
built inside of debian, etc. So I think I understand better what is 
being installed where, so again, disregard the last email.

I've gotten a package to correctly deliver a .bin to a folder  
successfully run that on install.

Ha

thx for your patience.

eric

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

Re: newbie packaging question

[Eric Winger]

oops, shouldn't have posted so soon. I found the dpkg -i .deb option. 
I'll work through that. sorry

Matthew Palmer wrote:

On Mon, Aug 11, 2003 at 04:16:31PM -0700, Eric Winger wrote:
 thx to all for the responses. I'm slowly making progress here. Could
 someone distinguish the configuration section and how that applies to
 debian packages for me (the eternal newbie).
There are several configuration sections you need to take into account.
They are typically split into package creation, package 
installation and
runtime configuration.  Package creation config is what's in the 
debian/
directory of your package source.  Installation time config are 
known as
maintainer scripts - they consist of the preinst, postinst, prerm, and
postrm scripts run at the appropriate time during configuration, and also
the debconf scripts (which I'm presuming you won't need at this stage).

 I was under the impression that the configuration rules were what the
 package would run after it was loaded. However, when I did a fakeroot
 against my simplistic package, it actually ran the config rules which
 surprised me.
Did a fakeroot as 'in ran fakeroot debian/rules in your package 
source
directory'?  Then the config files you're talking about are probably
debian/rules and friends.

 Can someone clarify. I'm looking to create the simple .deb package, 
then
 put in a 'post load' method which runs the binary i'm putting in the
 package.

At installation time?  You'll want to add an appropriate command to the
postinst script.  That file gets run after the package's files are 
unpacked
into their respective locations in the filesystem.

 Also (really really stupid question).. where do i get these sources for
 the packages you guys mentioned?
The easiest way for packages in the actual archive is to run 'apt-get 
source
package'.  That'll download the sources and unpack them into the 
current
directory.

- Matt

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



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

Re: newbie packaging question

[Goswin von Brederlow]

Eric Winger [EMAIL PROTECTED] writes:

 ok, I've managed to make a .deb file  a big ol tarball. Questions:
 * I thought that the .deb file would end up containing all of my
 * files, but the only thing that could possible hold my source is the
 * big tarball that dpkg-buildpackage built for me. Does this seem
 * correct?

The *.deb files are usually only the compiled binaries (ignoring -dev,
-doc and source-bla debs).

Sources are in the (.orig).tar.gz, diff.gz (if .orig) and dsc
(organizing the former files).

MfG
Goswin


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

Re: newbie packaging question

[Goswin von Brederlow]

Hi,

by the way, do you use debuild to build your package?

That way Debian will do some more checks before and after build like
build dependencies and lintian runs. Lintian will catch a lot of
little mistakes one can make like having *.ex files still in the
package. Listen to it.

MfG
Goswin


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

Re: newbie packaging question

[Leo \Costela\ Antunes]

On Ter, 2003-08-12 at 14:38, Eric Winger wrote:
 * all the deb-src entries i tried to add to my sources.list give me 
 errors when I try to get the source. What is the url for sources? This 
 is my latest attempt:
 
 deb-src ftp://ftp.debian.org/debian testing main contrib free

My sources.list has:

deb-src http://http.us.debian.org/debian unstable main contrib non-free

Change unstable for the distribution you use.
Why the hell did you put free in there? That's redundant! =]

Hope this works out for you.

Cheers
-- 

 Leo Costela
 [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED]
 Key Fingerprint: 8AE6 CDFF 6535 192F B5B6 5921 2262 D36F 7ADF 9466
 you must cut down the mightiest tree in the forest... with... a herring!


signature.asc
Description: This is a digitally signed message part

Re: newbie packaging question

[Colin Watson]

On Tue, Aug 12, 2003 at 04:40:42PM -0700, Eric Winger wrote:
 Ok, I've managed to create a .deb package, experimented with putting 
 things in the rules file, installed my package locally. Learned a little 
 about purge and kind of have the gist of what y'all have been trying to 
 pound into my head.
 
 But now I've run into a problem. For my first package, which is nothing 
 but a test. I want to be able to run some commands after my package has 
 been installed. Simple copy  execute commands.
 
 I've modified the postinst.ex file, but my commands aren't being 
 executed.

You must rename that to postinst. Your completed source package
shouldn't have any of those example *.ex files in it.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]


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

Re: newbie packaging question

[Matthew Palmer]

On Thu, Aug 07, 2003 at 12:54:08PM -0700, Eric Winger wrote:
 I hope that I've selected the correct debian mailing list for this 
 question. But if not, I would appreciate if you could redirect properly.

Nope, this is the right spot.

 My first steps are proving to be quite haltingly slow. I'm the Debian 
 New Maintainer's Guide and I've setup a simple goal for myself. To take 
 an installation .bin (known to work) and make a debian package out of 
 it. No sources, just a .bin. Then debian, upon installing this package, 
 would simply run a little config script to run the .bin file.

Ayup.  Quite simple.

 But in following the instructions in the doc it tells me to create some 
 directories with my source in them, then use dh-make first. But dh_make 
 keeps telling me it can't find my source package.

That would be the tarball containing the source for your package.  The
source is simply whatever gets released without debian modifications.  Of
course, there are debian native packages, where the source and debian bits
are all together.

The things which absolutely have to be in a package in order to be built are
debian/rules and debian/control.  debian/rules gives the commands required
to make the package, and debian/control has the information necessary to
name the binary packages, dependencies, and the rest.

Your best bet is to get the source for a really simple, debian-native,
architecture-independent package, and change the small bit of code that has
to be changed to copy your binary to the right place.

Executing commands after installation can be done in the postinst file,
which is usually just a shell script.  Adding a startup script can be done
with dh_installinit (see the manpage).

An example of a simple package as described above is phtml.  (Mandatory
disclosure: I maintain it).

 So two questions, does the source package need to be raw code or is it 
 specific term to refer to a C source filled directory? And two, is my 
 goal reasonable for a first-timer?

Your goal is reasonable, and no, source code doesn't have to be C source
or anything like that.  Consider doc-rfc, or Perl script packages.

- Matt


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

Re: newbie packaging question

[Goswin von Brederlow]

Hi,

by the way, do you use debuild to build your package?

That way Debian will do some more checks before and after build like
build dependencies and lintian runs. Lintian will catch a lot of
little mistakes one can make like having *.ex files still in the
package. Listen to it.

MfG
Goswin

Re: newbie packaging question

[Eric Winger]

I've been able to build a package, install it, get a postinst script to 
run properly. Now, I'm at the point in my little test where 
understanding where everything goes during install is important.


I'm moving away from using New Deb Maintainer docs and trying to follow 
advice given in this forum, and looking at simple packages and how they 
do things. In particular, I'm trying to figure out why phtml copies 
files during the build process. That doesn't make sense to me because it 
seems like one could put those in the proper directory before the 
package build.


So to simplify the questions:
* why does phtml do a copy in the rules file install step?
* what links are available to start to explain where things should go  
do go during the install process?

* what would be the (current directory) during an apt-get install?

I suspect there are links to this general type of question already.  In 
the meantime, Ill keep browsing the docs I have. Hopefully, the kind of 
questions I'm working on are clear. Because they effect things like 
purge  remove steps too.


thx

Eric

Matthew Palmer wrote:


On Thu, Aug 07, 2003 at 12:54:08PM -0700, Eric Winger wrote:
 I hope that I've selected the correct debian mailing list for this
 question. But if not, I would appreciate if you could redirect 
properly.


Nope, this is the right spot.

 My first steps are proving to be quite haltingly slow. I'm the Debian
 New Maintainer's Guide and I've setup a simple goal for myself. To take
 an installation .bin (known to work) and make a debian package out of
 it. No sources, just a .bin. Then debian, upon installing this package,
 would simply run a little config script to run the .bin file.

Ayup.  Quite simple.

 But in following the instructions in the doc it tells me to create some
 directories with my source in them, then use dh-make first. But dh_make
 keeps telling me it can't find my source package.

That would be the tarball containing the source for your package.  The
source is simply whatever gets released without debian 
modifications.  Of
course, there are debian native packages, where the source and 
debian bits

are all together.

The things which absolutely have to be in a package in order to be 
built are
debian/rules and debian/control.  debian/rules gives the commands 
required

to make the package, and debian/control has the information necessary to
name the binary packages, dependencies, and the rest.

Your best bet is to get the source for a really simple, debian-native,
architecture-independent package, and change the small bit of code 
that has

to be changed to copy your binary to the right place.

Executing commands after installation can be done in the postinst file,
which is usually just a shell script.  Adding a startup script can be 
done

with dh_installinit (see the manpage).

An example of a simple package as described above is phtml.  (Mandatory
disclosure: I maintain it).

 So two questions, does the source package need to be raw code or is it
 specific term to refer to a C source filled directory? And two, is my
 goal reasonable for a first-timer?

Your goal is reasonable, and no, source code doesn't have to be C 
source

or anything like that.  Consider doc-rfc, or Perl script packages.

- Matt


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

Re: newbie packaging question

[Eric Winger]

Goswin von Brederlow wrote:


Hi,

by the way, do you use debuild to build your package?


I'm using dpkg-buildpackage -rfakeroot


That way Debian will do some more checks before and after build like
build dependencies and lintian runs. Lintian will catch a lot of
little mistakes one can make like having *.ex files still in the
package. Listen to it.


I will look at that as well, thx.


MfG
Goswin

Re: newbie packaging question (I get it!)

[Eric Winger]

Ok, I got a few more things understood including what directories get 
built inside of debian, etc. So I think I understand better what is 
being installed where, so again, disregard the last email.


I've gotten a package to correctly deliver a .bin to a folder  
successfully run that on install.


Ha

thx for your patience.

eric

Re: newbie packaging question

[Thomas Viehmann]

 Will the packaging tools complain if you have no copyright file, too?  I
 know it's necessary for uploading, of course, and I'm sure lintian would
 have a right whinge, but will (eg) debhelper scripts have a complain, to
 your knowledge?
Nope. Neither dpkg-* nor debhelper will complain. (Tried with dupload and dput.)

Cheers

T.


pgp0.pgp
Description: PGP signature

Re: newbie packaging question

[Eric Winger]

Matthew Palmer wrote:

The easiest way for packages in the actual archive is to run 'apt-get 
source
package'.  That'll download the sources and unpack them into the 
current

directory.

Ahh, this brings up a point that has bothered me about debian. Well 
actually in this case, two points.


* all the deb-src entries i tried to add to my sources.list give me 
errors when I try to get the source. What is the url for sources? This 
is my latest attempt:


deb-src ftp://ftp.debian.org/debian testing main contrib free

also tried woody, main, etc.

* how can one keep up on what the latest url's are for debian packages 
etc. Is there a single spot where one can look? Or is this knowledge I 
will only gain when I use the force?


thx

eric

Re: newbie packaging question

[Colin Watson]

On Tue, Aug 12, 2003 at 10:38:06AM -0700, Eric Winger wrote:
 Matthew Palmer wrote:
 The easiest way for packages in the actual archive is to run 'apt-get
 source package'.  That'll download the sources and unpack them into
 the current directory.
 
 Ahh, this brings up a point that has bothered me about debian. Well 
 actually in this case, two points.
 
 * all the deb-src entries i tried to add to my sources.list give me 
 errors when I try to get the source. What is the url for sources? This 
 is my latest attempt:
 
 deb-src ftp://ftp.debian.org/debian testing main contrib free

That's correct except that you want non-free there, not free. (Ever
think you'd hear a Debian developer say that?)

 * how can one keep up on what the latest url's are for debian packages 
 etc. Is there a single spot where one can look? Or is this knowledge I 
 will only gain when I use the force?

I found it easiest (years ago) to read the sources.list(5) man page and
learn how those lines map into URLs, so I can then just go off with a
web browser or an FTP client, figure out what URL I need, and construct
the sources.list line from there.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: newbie packaging question

[Leo \Costela\ Antunes]

On Ter, 2003-08-12 at 14:38, Eric Winger wrote:
 * all the deb-src entries i tried to add to my sources.list give me 
 errors when I try to get the source. What is the url for sources? This 
 is my latest attempt:
 
 deb-src ftp://ftp.debian.org/debian testing main contrib free

My sources.list has:

deb-src http://http.us.debian.org/debian unstable main contrib non-free

Change unstable for the distribution you use.
Why the hell did you put free in there? That's redundant! =]

Hope this works out for you.

Cheers
-- 

 Leo Costela
 [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED]
 Key Fingerprint: 8AE6 CDFF 6535 192F B5B6 5921 2262 D36F 7ADF 9466
 you must cut down the mightiest tree in the forest... with... a herring!


signature.asc
Description: This is a digitally signed message part

Re: newbie packaging question

[Eric Winger]

Colin Watson wrote:

That's correct except that you want non-free there, not free. 
(Ever think you'd hear a Debian developer say that?)



would it be sacreligious to ask why sources are kept in non-free?


I found it easiest (years ago) to read the sources.list(5) man page and
learn how those lines map into URLs, so I can then just go off with a
web browser or an FTP client, figure out what URL I need, and construct
the sources.list line from there.


will go reread that. I had only skimmed it before.

thx

am slowly starting to begin to see a glimpse of the light of comprehension.

eric


--
Colin Watson  [EMAIL PROTECTED]


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

Re: newbie packaging question

[David Z Maze]

Eric Winger [EMAIL PROTECTED] writes:

 Ahh, this brings up a point that has bothered me about debian. Well
 actually in this case, two points.

 * all the deb-src entries i tried to add to my sources.list give me
 * errors when I try to get the source. What is the url for sources? 
 * This is my latest attempt:

 deb-src ftp://ftp.debian.org/debian testing main contrib free

That should work fine (well, modulo 'free' not existing; do you mean
'non-free'?).  Have you run 'apt-get update' (or a dselect or
atptitude update) before trying to run 'apt-get source'?  What errors
do you get?

 * how can one keep up on what the latest url's are for debian packages
 * etc. Is there a single spot where one can look? Or is this knowledge
 * I will only gain when I use the force?

It's in the Packages file that 'apt-get update' and friends download.
You can also look on http://packages.debian.org/, or in
debian/pool/main/l/lm-sensors (where lm-sensors is the source package
name, 'l' is its first letter, and library source packages begin with
'libl' or whatever) on your favorite Debian mirror.

-- 
David Maze [EMAIL PROTECTED]  http://people.debian.org/~dmaze/
Theoretical politics is interesting.  Politicking should be illegal.
-- Abra Mitchell

Re: newbie packaging question

[Eric Winger]

oops, shouldn't have posted so soon. I found the dpkg -i .deb option. 
I'll work through that. sorry


Matthew Palmer wrote:


On Mon, Aug 11, 2003 at 04:16:31PM -0700, Eric Winger wrote:
 thx to all for the responses. I'm slowly making progress here. Could
 someone distinguish the configuration section and how that applies to
 debian packages for me (the eternal newbie).

There are several configuration sections you need to take into account.
They are typically split into package creation, package 
installation and
runtime configuration.  Package creation config is what's in the 
debian/
directory of your package source.  Installation time config are 
known as

maintainer scripts - they consist of the preinst, postinst, prerm, and
postrm scripts run at the appropriate time during configuration, and also
the debconf scripts (which I'm presuming you won't need at this stage).

 I was under the impression that the configuration rules were what the
 package would run after it was loaded. However, when I did a fakeroot
 against my simplistic package, it actually ran the config rules which
 surprised me.

Did a fakeroot as 'in ran fakeroot debian/rules in your package 
source

directory'?  Then the config files you're talking about are probably
debian/rules and friends.

 Can someone clarify. I'm looking to create the simple .deb package, 
then

 put in a 'post load' method which runs the binary i'm putting in the
 package.

At installation time?  You'll want to add an appropriate command to the
postinst script.  That file gets run after the package's files are 
unpacked

into their respective locations in the filesystem.

 Also (really really stupid question).. where do i get these sources for
 the packages you guys mentioned?

The easiest way for packages in the actual archive is to run 'apt-get 
source
package'.  That'll download the sources and unpack them into the 
current

directory.

- Matt


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

Re: newbie packaging question

[Goswin von Brederlow]

Eric Winger [EMAIL PROTECTED] writes:

 ok, I've managed to make a .deb file  a big ol tarball. Questions:
 * I thought that the .deb file would end up containing all of my
 * files, but the only thing that could possible hold my source is the
 * big tarball that dpkg-buildpackage built for me. Does this seem
 * correct?

The *.deb files are usually only the compiled binaries (ignoring -dev,
-doc and source-bla debs).

Sources are in the (.orig).tar.gz, diff.gz (if .orig) and dsc
(organizing the former files).

MfG
Goswin

Re: newbie packaging question

[Bob Proulx]

Eric Winger wrote:
 would it be sacreligious to ask why sources are kept in non-free?

You are asking an obvious question and the answer is the obvious one.
The sources are in non-free because they are not free.  Look at the
copyrights of any of the packages in non-free and you will see that
they all have some type of restriction.

Bob


pgpWMrXBEvl9y.pgp
Description: PGP signature

Re: newbie packaging question

[Eric Winger]

Ok, I've managed to create a .deb package, experimented with putting 
things in the rules file, installed my package locally. Learned a little 
about purge and kind of have the gist of what y'all have been trying to 
pound into my head.


But now I've run into a problem. For my first package, which is nothing 
but a test. I want to be able to run some commands after my package has 
been installed. Simple copy  execute commands.


I've modified the postinst.ex file, but my commands aren't being 
executed. And the Debian New Maintainers' Guide says I shouldn't do this 
(add to maintainer scripts) yet. So that tells me I should be putting my 
configuration commands for the just installed package somewhere else.


Any ideas? Or is the postinst.ex file correct, and i may be not writing 
the script correctly. I just added:


cp myFile /hardcoded path/
./path/myFile (wishing to run that file)

thx

Eric

Re: newbie packaging question

[Colin Watson]

On Tue, Aug 12, 2003 at 11:53:27AM -0700, Eric Winger wrote:
 Colin Watson wrote:
 That's correct except that you want non-free there, not free. 
 (Ever think you'd hear a Debian developer say that?)
 
 would it be sacreligious to ask why sources are kept in non-free?

I think one of us is confused. :) Source for non-free packages is in
non-free, but if you aren't interested in that or would rather avoid it
you're of course entirely welcome to omit the non-free word from that
line.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: newbie packaging question

[Joshua Kwan]

On Tue, Aug 12, 2003 at 04:40:42PM -0700, Eric Winger wrote:
 Any ideas? Or is the postinst.ex file correct, and i may be not writing 
 the script correctly. I just added:
 
 cp myFile /hardcoded path/
 ./path/myFile (wishing to run that file)

.ex stands for example. remove the .ex.

I suggest that instead of using newmaint as your bible, source a few
simple packages and look at how they do things.

--
Joshua Kwan


pgpSt7F67YqDB.pgp
Description: PGP signature

Re: newbie packaging question

[Keegan Quinn]

On Tue, Aug 12, 2003 at 04:40:42PM -0700, Eric Winger wrote:
 I've modified the postinst.ex file, but my commands aren't being 
 executed. And the Debian New Maintainers' Guide says I shouldn't do this 
 (add to maintainer scripts) yet. So that tells me I should be putting my 
 configuration commands for the just installed package somewhere else.

You need to rename postinst.ex to just postinst, I think.

 - Keegan


pgpy5WHZbJxfn.pgp
Description: PGP signature

Re: newbie packaging question

[Colin Watson]

On Tue, Aug 12, 2003 at 04:40:42PM -0700, Eric Winger wrote:
 Ok, I've managed to create a .deb package, experimented with putting 
 things in the rules file, installed my package locally. Learned a little 
 about purge and kind of have the gist of what y'all have been trying to 
 pound into my head.
 
 But now I've run into a problem. For my first package, which is nothing 
 but a test. I want to be able to run some commands after my package has 
 been installed. Simple copy  execute commands.
 
 I've modified the postinst.ex file, but my commands aren't being 
 executed.

You must rename that to postinst. Your completed source package
shouldn't have any of those example *.ex files in it.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: newbie packaging question

[Eric Winger]

thx to all for the responses. I'm slowly making progress here. Could 
someone distinguish the configuration section and how that applies to 
debian packages for me (the eternal newbie).


I was under the impression that the configuration rules were what the 
package would run after it was loaded. However, when I did a fakeroot 
against my simplistic package, it actually ran the config rules which 
surprised me.


Can someone clarify. I'm looking to create the simple .deb package, then 
put in a 'post load' method which runs the binary i'm putting in the 
package.


Also (really really stupid question).. where do i get these sources for 
the packages you guys mentioned?


Eric

Bernhard R. Link wrote:


* Eric Winger [EMAIL PROTECTED] [030807 21:54]:
 But in following the instructions in the doc it tells me to create some
 directories with my source in them, then use dh-make first. But dh_make
 keeps telling me it can't find my source package.

dh_make is optimized to create source packages that automatically create
the binary package. While it is an also be a nice (though not the
easiest) way to create a .deb out of some upstream binaries, you have
to understand debhelper a bit more than when using it for waht it was
made.
The easiest way is to start with an empty source, i.e. create an
emtpy directory containing a version number, like
mkdir blafasel-1.0
cd blafasel-1.0
dh_make -n -s -e [EMAIL PROTECTED]

which should create a debian/-subdirectory with everything needed in it.
In debian/rules just remove the calls to make, and you can already
create an (almost) empty .deb, by calling fakeroot ./debian/rules.
(or dpkg-buildpackage -rfakeroot -B, if you prefer this).
Then just add the proper commands in debian/rules to get the programs
installed to debian/tmp or debian/name depending on what DH_COMPAT
you have set and remove those files in debian/ you do not need, and
perhaps adopting the control and changelog (and the copyright-file
as it will contain GPL by default) would be a nice idea.

Hochachtungsvoll,
  Bernhard R. Link

--
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.

Re: newbie packaging question

[Eric Winger]

should have added that I also tried the fakeroot /debian/rules binary to 
build the .deb, but it just told me that it didn't find a file on a line 
that didn't exist in my /rules file.


eric


Winger, Eric wrote:


thx to all for the responses. I'm slowly making progress here. Could
someone distinguish the configuration section and how that applies to
debian packages for me (the eternal newbie).

I was under the impression that the configuration rules were what the
package would run after it was loaded. However, when I did a fakeroot
against my simplistic package, it actually ran the config rules which
surprised me.

Can someone clarify. I'm looking to create the simple .deb package, then
put in a 'post load' method which runs the binary i'm putting in the
package.

Also (really really stupid question).. where do i get these sources for
the packages you guys mentioned?

Eric

Bernhard R. Link wrote:

 * Eric Winger [EMAIL PROTECTED] [030807 21:54]:
  But in following the instructions in the doc it tells me to create 
some
  directories with my source in them, then use dh-make first. But 
dh_make

  keeps telling me it can't find my source package.

 dh_make is optimized to create source packages that automatically 
create

 the binary package. While it is an also be a nice (though not the
 easiest) way to create a .deb out of some upstream binaries, you have
 to understand debhelper a bit more than when using it for waht it was
 made.
 The easiest way is to start with an empty source, i.e. create an
 emtpy directory containing a version number, like
 mkdir blafasel-1.0
 cd blafasel-1.0
 dh_make -n -s -e [EMAIL PROTECTED]

 which should create a debian/-subdirectory with everything needed in 
it.

 In debian/rules just remove the calls to make, and you can already
 create an (almost) empty .deb, by calling fakeroot ./debian/rules.
 (or dpkg-buildpackage -rfakeroot -B, if you prefer this).
 Then just add the proper commands in debian/rules to get the programs
 installed to debian/tmp or debian/name depending on what DH_COMPAT
 you have set and remove those files in debian/ you do not need, and
 perhaps adopting the control and changelog (and the copyright-file
 as it will contain GPL by default) would be a nice idea.

 Hochachtungsvoll,
   Bernhard R. Link

 --
 Sendmail is like emacs: A nice operating system, but missing
 an editor and a MTA.



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

Re: newbie packaging question

[Matthew Palmer]

On Mon, Aug 11, 2003 at 04:16:31PM -0700, Eric Winger wrote:
 thx to all for the responses. I'm slowly making progress here. Could 
 someone distinguish the configuration section and how that applies to 
 debian packages for me (the eternal newbie).

There are several configuration sections you need to take into account. 
They are typically split into package creation, package installation and
runtime configuration.  Package creation config is what's in the debian/
directory of your package source.  Installation time config are known as
maintainer scripts - they consist of the preinst, postinst, prerm, and
postrm scripts run at the appropriate time during configuration, and also
the debconf scripts (which I'm presuming you won't need at this stage).

 I was under the impression that the configuration rules were what the 
 package would run after it was loaded. However, when I did a fakeroot 
 against my simplistic package, it actually ran the config rules which 
 surprised me.

Did a fakeroot as 'in ran fakeroot debian/rules in your package source
directory'?  Then the config files you're talking about are probably
debian/rules and friends.

 Can someone clarify. I'm looking to create the simple .deb package, then 
 put in a 'post load' method which runs the binary i'm putting in the 
 package.

At installation time?  You'll want to add an appropriate command to the
postinst script.  That file gets run after the package's files are unpacked
into their respective locations in the filesystem.

 Also (really really stupid question).. where do i get these sources for 
 the packages you guys mentioned?

The easiest way for packages in the actual archive is to run 'apt-get source
package'.  That'll download the sources and unpack them into the current
directory.

- Matt

Re: newbie packaging question

[Colin Watson]

On Fri, Aug 08, 2003 at 07:38:11PM +1000, Matthew Palmer wrote:
 The things which absolutely have to be in a package in order to be
 built are debian/rules and debian/control.  debian/rules gives the
 commands required to make the package, and debian/control has the
 information necessary to name the binary packages, dependencies, and
 the rest.

debian/changelog must also be present.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]


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

Re: newbie packaging question

[Colin Watson]

On Fri, Aug 08, 2003 at 10:12:52PM +1000, Matthew Palmer wrote:
 On Fri, Aug 08, 2003 at 11:24:13AM +0100, Colin Watson wrote:
  On Fri, Aug 08, 2003 at 07:38:11PM +1000, Matthew Palmer wrote:
   The things which absolutely have to be in a package in order to be
   built are debian/rules and debian/control.  debian/rules gives the
   commands required to make the package, and debian/control has the
   information necessary to name the binary packages, dependencies, and
   the rest.
  
  debian/changelog must also be present.
 
 D'oh.  Knew I forgot something.
 
 Will the packaging tools complain if you have no copyright file, too?  I
 know it's necessary for uploading, of course, and I'm sure lintian would
 have a right whinge, but will (eg) debhelper scripts have a complain, to
 your knowledge?

Don't think so; dh_installdocs is the only thing that cares about the
copyright file at all, and looking at the source it doesn't look like
it'll mind if it doesn't exist. I've certainly built quick test packages
in the past without copyright files and had no problems other than the
obvious lintian warning.

I think this is correct behaviour, really. After all, packaging tools
should be general where it's reasonable to be, and the copyright file is
exclusively a Debian policy thing.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]


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

Re: newbie packaging question

[Matthew Palmer]

On Thu, Aug 07, 2003 at 12:54:08PM -0700, Eric Winger wrote:
 I hope that I've selected the correct debian mailing list for this 
 question. But if not, I would appreciate if you could redirect properly.

Nope, this is the right spot.

 My first steps are proving to be quite haltingly slow. I'm the Debian 
 New Maintainer's Guide and I've setup a simple goal for myself. To take 
 an installation .bin (known to work) and make a debian package out of 
 it. No sources, just a .bin. Then debian, upon installing this package, 
 would simply run a little config script to run the .bin file.

Ayup.  Quite simple.

 But in following the instructions in the doc it tells me to create some 
 directories with my source in them, then use dh-make first. But dh_make 
 keeps telling me it can't find my source package.

That would be the tarball containing the source for your package.  The
source is simply whatever gets released without debian modifications.  Of
course, there are debian native packages, where the source and debian bits
are all together.

The things which absolutely have to be in a package in order to be built are
debian/rules and debian/control.  debian/rules gives the commands required
to make the package, and debian/control has the information necessary to
name the binary packages, dependencies, and the rest.

Your best bet is to get the source for a really simple, debian-native,
architecture-independent package, and change the small bit of code that has
to be changed to copy your binary to the right place.

Executing commands after installation can be done in the postinst file,
which is usually just a shell script.  Adding a startup script can be done
with dh_installinit (see the manpage).

An example of a simple package as described above is phtml.  (Mandatory
disclosure: I maintain it).

 So two questions, does the source package need to be raw code or is it 
 specific term to refer to a C source filled directory? And two, is my 
 goal reasonable for a first-timer?

Your goal is reasonable, and no, source code doesn't have to be C source
or anything like that.  Consider doc-rfc, or Perl script packages.

- Matt

Re: newbie packaging question

[Colin Watson]

On Fri, Aug 08, 2003 at 07:38:11PM +1000, Matthew Palmer wrote:
 The things which absolutely have to be in a package in order to be
 built are debian/rules and debian/control.  debian/rules gives the
 commands required to make the package, and debian/control has the
 information necessary to name the binary packages, dependencies, and
 the rest.

debian/changelog must also be present.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: newbie packaging question

[Matthew Palmer]

On Fri, Aug 08, 2003 at 11:24:13AM +0100, Colin Watson wrote:
 On Fri, Aug 08, 2003 at 07:38:11PM +1000, Matthew Palmer wrote:
  The things which absolutely have to be in a package in order to be
  built are debian/rules and debian/control.  debian/rules gives the
  commands required to make the package, and debian/control has the
  information necessary to name the binary packages, dependencies, and
  the rest.
 
 debian/changelog must also be present.

D'oh.  Knew I forgot something.

Will the packaging tools complain if you have no copyright file, too?  I
know it's necessary for uploading, of course, and I'm sure lintian would
have a right whinge, but will (eg) debhelper scripts have a complain, to
your knowledge?

(I should just rename a copyright file and try it out, but I like mailing
list discussions... grin)

- Matt

Re: newbie packaging question

[Thomas Viehmann]

 Will the packaging tools complain if you have no copyright file, too?  I
 know it's necessary for uploading, of course, and I'm sure lintian would
 have a right whinge, but will (eg) debhelper scripts have a complain, to
 your knowledge?
Nope. Neither dpkg-* nor debhelper will complain. (Tried with dupload and dput.)

Cheers

T.


pgpmS6pS68UIJ.pgp
Description: PGP signature