On Wed, Nov 03, 2004 at 04:06:01PM -0600, Zach Garner wrote:
> > Most of the apps are using `./configure && make && make install` so dh_make
> > tries to use that way.
> > In fact the only file you need is debian/rules.
> > It should be Makefile which create your package.
>
> What bugs me is that as far as I can tell from the documentation,
> dh_make is the recommended proper way of doing things. Also, as far as I
> can tell I need the following:
> README.Debian compat copyright rules control dirs
README.Debian, compat and dirs is useless (well at least it's not needed).
In fact you need copyright, when you write copyright issues (could be
easily checked how it looks like in other packages), rules (which is the
most important file which manages whole building process) and control which
could be also easily written cause it includes only most significant
issues.
> I understand your point though, the 'rules' file is the only one that
> really matters.
As I said previously... you can prepare rules file which will handle all
issues, but it's not so easy then.
> > If you really don'y like debhelper's scripts you can always write this
> > Makefile yourself or use cdbs (`apt-get install cdbs`).
>
> I'll look into cdbs.
That's totally other way of packaging. It's designed to simplify rules file
as much as it is possible.
Sorry I won't describe it more verbosely cause I like debhelper ;)
> I have some makefiles that work ok, by modifying what I got from dh_make
> (this is probably a bad idea, but I don't have documentation on how to
> hand write one without using debhelper scripts...) It generally works,
> but there is a lot of magic that happens in the dh_ scripts.
You can always check some examples. (Not sure if examples is proper name
cause they're just working and in most cases fully compliant packages ;))
Anyway... checking some really simple package should give you some ideas
what is being happen during packaging.
In fact compilation, moving to proper directory and calling dh_builddep
should be enough in most cases.
You have to use the same targets as in Debian's makefiles, but if you don't
care about policy compliant you can even miss that requirenment.
> For instance, I don't know how it knows that debian/<packagename> is where
> my application data is supposed to be. Is this hardcoded in dpkg-deb? Is
> somehow expressed in one of the dh_ scripts that is listed in my
> "binary:" target. All I really know is that if I put my files there, it
> puts them in the package. I probably need to read the man pages more
> than I have...
That is related to debian/control file.
Whole packaging scripts assume that every "Package: <whatever>" line in
debian/control is used for final packages.
So if you have:
Package: my_cool_package
line in debian/control then scripts looking for your files in
debian/my_cool_package directory. So just put there your files in proper
filesystem hierarchy and they'll be moved to package called the same.
> > > Second, why can't I create packages with standard unix commands? Why
> > > can't I say something like:
> > > $ tar cvzf data.tgz myapplication/*
> > > $ tar czvf control.tgz control
> > > $ tar czvf mypackage-0.1.deb data.tgz control.tgz
> >
> > Debian uses standard unix commands.
>
> What I meant by standard roughly translates into available on most/all
> unix or linux systems. The format of a .deb file is special as far as I
> can tell. I can't create or manipulate them without using dpkg-deb or
> one of the other scripts.
Well you can. But then it became even more hard to do.
You can use ar, tar and gzip.
You seems to ignore fact that Debian contains almost only free software,
and it is almost only build on Debian's autobuilders (excluding non-free
and contrib). So building scripts are designed to simplify *this* task, and
not packaging binary files.
Sorry that's the way it is. We're targeted at FREE SOFTWARE and our policy
demands to build it with another free software available on our
autobuiders.
It is however possible to build binary package in other way.
AFAIR there is some manual on the net how to easily do that.
Quick google search:
http://tldp.org/HOWTO/Debian-Binary-Package-Building-HOWTO/
> In fact, I would be happy enough if I could (a) run dpkg-deb on our
> other systems, this may be possible, though I don't expect it would too
> easy and (b) use dpkg-deb to create a package by giving it the
> control.tgz and data.tgz. Ideally, dpkg-deb wouldn't be required to
> create the specially formatted deb file, and I could just create a tar.
Take a look at mentioned link.
If you don't care our policy then use binary packaging.
> > > My main complaint here, is that we really want to be able to build the
> > > debian packages from any developer workstation. Since we don't impose
> > > operating system requirements on developers, we can't expect debian to
> > > be on all workstations.
> >
> > Sorry. How do you suppose to build rpm without rpm?
> Oh, I didn't mean to imply RPM was better here. My other biases show
> here.. I started out with Slackware, and later spent quite a while in
> the OpenBSD then FreeBSD world. For all of those .tgz was the standard
> format.
>
> I'm trying my best to put aside my previous habits, and get into the
> debian package building way of thought.
I didn't mean to imply advantage of Debian too ;)
> > > Right now, using Debian to deploy our software seems more and more
> > > difficult for us. I'd greatly appreciate any advice or comments. All I
> > > want to be able to do is create a package on any unix system that can be
> > > installed via apt-get, that simply installs some files, and can use the
> > > pre/post install/remove scripts. This seems like a simple thing to do,
> > > but the process seems very difficult.
> >
> > Is your software free? Can you share it with us?
> > I'm sure that someone create proper packaging scripts for you.
> > I'm first to help you if you want.
>
> Unfortunately, it's not. I greatly appreciate the help you've given so
> far, and the offer for more help. I can only promise that, if I start to
> like the debian package build process, that I will contribute back in my
> free time. I was once a FreeBSD package maintainer...
>
> I can get over part of my complaints. I can deal with the multiple files
> in the debian directory, and may come to love it. The layers of scripts,
> and the resulting confusing, conflicting documentation is still a
> problem. But I expect I can eventually come to an understanding of it
> all.
>
> What's still the big problem for us is the need to be on a debian system
> to create the packages. From what I can tell, we would likely need a few
> packages from debian-unstable on that system as well.
>
> This isn't a technically insurmountable problem, but it is a snag when
> it comes to convincing my supervisors that choosing debian and apt-get
> for our production platform was a great idea. (it's probably still the
> best idea, but unfortunately, maybe not a great one for our needs)
As I said. Try to build binary package. Should be much easier, and should
fit your needs ;)
Hope that helps.
regards
fEnIo
--
_ Bartosz Fenski | mailto:fenio@o2.pl | pgp:0x13fefc40 | IRC:fEnIo
_|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska
(0 0) phone:+48602383548 | Slackware - the weakest link
ooO--(_)--Ooo http://skawina.eu.org | JID:fenio@jabber.org | RLU:172001
Attachment:
signature.asc
Description: Digital signature