[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Tutorial: using proposed source packaging format as non-root



I didn't explain in detail how to use my proposed source packaging
format in my RFC, as it was not meant to be a tutorial.  Please read
the RFC before reading this tutorial.

There has been much confusion about whether or not it is possible to 
use the proposed format without root priviledges.

In fact, it is possible.  Actually, it is recommended that you don't
build your packages as root.

The example in the RFC did not use fakeroot, as it revealed some flaws in 
fakeroot, but I think those are bugs - I have figured out how to work 
around it.

Normally, packages are built on a system where the user has root
priviledges, and are tested that way.  So in typical usage, somebody
interested in building packages from source would add "hamm-source"
or "bo-source" to the list of distributions they would like to
see in dselect.  This way, dselect would use the Packages file
for the source distribution.  (It is just a conventional Packages
file, as these are just conventional .deb files)

For example, if you choose to install a src-deb-*.deb file, dselect
will automatically prompt you to also install the src-orig-*.deb
files containing the upstream source, because a dependency is
defined between them.

Remember, 

When you install the source .deb files, you are not actually installing
or even unpacking software - it is just placing files in the
/usr/src/debian directory.  If the upstream source was a .tar.gz file,
you will have that same file installed under /usr/src/debian.

The files installed under /usr/src/debian are owned by root.  But you 
are not required to do your compile in that directory.  In fact, I would
recommend not doing that.

Typically, you would compile everything in your own home directory.
Here is an example using fakeroot:

$ cd ~/tmp

 (I am now in my personal temporary directory)

$ make -f /usr/src/debian/src-deb-hello/Makefile unpack 

 (... stuff unpacks ...)

$ ls -l
total 1
drwxr-xr-x   2 jim      jim          1024 Oct 23 11:34 hello.src
-rw-r--r--   1 jim      jim             0 Oct 23 11:34 unpack

 (see, the source is unpacked in a subdir in my directory, owned by me)

$ make -f /usr/src/debian/src-deb-hello/Makefile build

 (the compile happens - a "build" timestamp file is created in my dir)

$ fakeroot /usr/bin/make -f /usr/src/debian/src-deb-hello/Makefile binary \
    finaldebdir=.

 (the package gets made)

$ ls -l
total 23
-rw-r--r--   1 jim      jim             0 Oct 23 11:39 build
-rw-r--r--   1 jim      jim            39 Oct 23 11:44 files
drwxr-xr-x   4 jim      jim          1024 Oct 23 11:43 hello.build
drwxr-xr-x   2 jim      jim          1024 Oct 23 11:39 hello.src
-rw-r--r--   1 jim      jim            21 Oct 23 11:43 hello.substvars
-rw-r--r--   1 jim      jim         17568 Oct 23 11:44 hello_1.3-13.1_i386.deb
-rw-r--r--   1 jim      jim             0 Oct 23 11:34 unpack

$ make -f /usr/src/debian/src-deb-hello/Makefile debclean

 (clean out files)

$ ls -l
total 19
-rw-r--r--   1 jim      jim         17568 Oct 23 11:44 hello_1.3-13.1_i386.deb

See, you never have to be root.  In this example, the src-*.deb packages
were installed using dpkg (as root), but even that can be avoided.

If you don't like doing "make -f /usr/src/debian/src-deb-<packagename>"
all the time, just set up a shell alias.

Here is an example where some src-*.deb files are installed and built, but
not using dpkg.  Instead, they are installed using dpkg-deb, which does
not require root priviledges.  Of course, you need to install them in a
non-default location, since you can't (shouldn't) install them to
/usr/src/debian as that location is for source installed using dpkg.

$ cd ~/tmp
$ dpkg-deb --extract src-deb-hello_1.3-1.1_all.deb .
$ dpkg-deb --extract src-orig-hello_1.3-1_all.deb .
$ make -f usr/src/debian/src-deb-hello/Makefile srcdebiandir=usr/src/debian
$ fakeroot /usr/bin/make -f usr/src/debian/src-deb-hello/Makefile \
    srcdebiandir=usr/src/debian binary finaldebdir=.

This is the technique you would want to use if you intend on actually
modifying the source package.

Building a debian-specific source package would be done by a simple script, 
such as:

$ dpkg-source-proposed --build usr/src/debian/src-deb-hello

Which would create a src-deb-hello_x.x-x_all.deb file.  There needs to
be an additional file in the directory so it can figure out what goes
into the control file.

(Essentially the same thing as the current dpkg-source, perhaps it
 could even be done by that same command)

The upstream source package would be build the exact same way:

$ dpkg-source-proposed --build usr/src/debian/src-orig-hello


That's the end of the tutorial.

:-)

Now a word on philosophy.

A lot of the opposition to my proposal seems to be aestheticly
based -- essentially "dpkg-source is for source, dpkg is for binaries".

I don't buy into that philosophy.  I find dpkg is an excellent tool
for gaining control over my system.  That's the way I approach it
 -- a control tool (I am a control systems engineer after all).

I believe the application space that dpkg (and rpm) occupies is a
very important one.  These systems provide mechanisms and boundaries for
installing outside software and data into a computer system.  A 
computer system consists of more than just binary files -- it also consists 
of documentation, data, source, live data streams and many other things.
 
I believe dpkg (and rpm) would work as an excellent tool for install 
and de-installing packages in root as well as user space.  Currently, 
dpkg has little support for installing packages (binary and source)
into user space, but it can (and will) be added.

I would like to see the .deb file format used for much more than just
installing binaries.  For example, it is an excellent documentation
delivery format.  It could be used to implement "push" channels of
information with automated delivery mechanisms (ie. my debdelta
proposal).  It could act as an alternative to what Microsoft, Netscape
and Marimba are trying to advocate as a medium for software and
information delivery.  One that puts control in the hands of the
users, and not in commercial software and media entities.

But it needs more work to get to this stage.  A lot more work.
It would be folly to assume that we have a packaging system that
is anywhere near complete.  Keep this in mind when you make your
choice as to which software technologies you want to use to
keep your world in order.

Cheers,

 - Jim

Attachment: pgppRfR1OjaY4.pgp
Description: PGP signature


Reply to: