bruce@pixar.com (Bruce Perens) writes:
> > I don't think that Debian stuff should go upstream.
>
> Do you offer any justification for that? I think it's a really nice feature
> when Debian stuff is built into a software package and no diff is necessary.
Have you used automake? It does a pretty good job. We should get a few
macros included into the upstream automake distribution so somebody can
add support for Debian menus, alternatives, documentation files, etc. just
by calling a few extra macros in their Makefile.am's (I think). The nice
thing is that this doesn't have to be targetted solely at Debian. There
could be Red Hat hooks as well. I think even Ted Ts'o could go along with
that. Good luck getting him to put a debian directory into e2fsprogs.
Of course, not everybody uses automake.
> > You are correct, the stuff doesn't get unpacked automatically.
> > I think that's a good thing -- why waste disk space if you aren't
> > currently involved in the process of building a package?
>
> In that case, why install the source package at all, instead of waiting
> until the moment I need it?
So you have it hanging around. I'm only connected to the net by a 28.8
modem at my office. It would be nice to use dpkg-ftp to grab all the source
packages you want, and have them automatically installed (still compressed)
in a convenient place on the drive.
> > I have an easy solution for this - make a modified dpkg that understands
> > a "pseudo-package" that doesn't really exist - but when you install it
> > with dpkg, dpkg will compile it from sources. That way, all we have to
> > do is generate "pseudo-package" descriptions for all the binary debs
> > we want, and invoke dpkg, and it will do everything in the right order.
> > (Well, hopefully - maybe Manoj's pkgorder would help)
> > Seems like a pretty quick hack to me, although I am uncomfortable with
> > the inards of dpkg.
>
> I would feel a whole lot more comfortable if this was not overloaded on
> top of our binary package database. For example, we've just doubled the
> number of packages in the package listing. We can hack dselect to not
> display them, but why are we hacking dpkg/dselect here? To avoid building
> a clean tool to handle the source package task and no other task.
Actually, I rethought this - there is no reason to even touch dpkg. I think
Manoj's pkg-order package can do everything for us. I'm going to do some
more experimenting -- this might be an awesome way to bootstrap the GNU/Win32
stuff.
As far as doubling the number of packages in the package listing - big deal,
it's already overloaded in dpkg. Diety is supposed to address this. It's
a UI issue, which is peripheral to the real problem. There aren't any
additional files for the ftp repository, since each orig.tar.gz file gets
replaced by a src-orig-*.deb file, and each src-deb-*.deb file replaces
a .diff.gz file. And we can get rid of the .dsc files completely.
> [Dependencies work on source removal too, which is problematical]
> > How so? If you don't like the dependencies, just use
> > "dpkg --purge --force-depends".
>
> Here we drag dpkg into something it doesn't want to do, because we are
> using it for something it wasn't intended for. I'd prefer not to get people
> trained to use the --force-depends flag.
I guess I'm not really clear on your problem here - can you give me an
example. With the little "hello" program I made up, I can nuke the source
after I compiled by just doing 'dpkg --purge src-orig-hello src-deb-hello'.
There isn't any dependency from the binary package to the source packages.
> >> If I am not mistaken, _all_ source dependencies are actually binary
> >> dependencies, because they need the source to be _built_and_installed_.
> >
> > Not really, the debian source package might require uncompiled source
> > or header files from other (upstream) source packages.
>
> Only in the case of circular dependencies between packages should it be
> handled that way. Otherwise, the other packages should be built and
> installed first. If you are building piece-mal, the packages you depend
> on do not need to be built at all, just installed from binary packages.
Warning - you are creating special cases here when we can do without.
I think the terminology might be getting confused. Here's what the terms
I am using mean:
Binary Dependency - a package containing binaries (libraries or executables)
is needed in order for the dependent package to be run or compiled.
ie. many packages depend on libc5 or libc6
-or-
many source packages depend on debmake in order be built
Source Dependency - a package containing source (upstream or Debian-specific)
is needed in order for the dependent package to be compiled.
Compilation Dependency - a pseudo-package representing a non-existent
package will be dependent on the source package which generates it.
Auto-compilation consists of a process where these dependencies are
eliminated as pseudo-packages are "installed". When a pseudo package
is "installed" - it is really just compiled, and a real package is
installed it's place. When this happens, the dependency graph has
changed, since the compilation dependency no longer exists. So the
system is no longer dependent on the source packages.
These are all dependencies.
The algorithm for auto-compilation would start out with a bunch of upstream
and debian-specific source packages with dependencies between themselves
(and perhaps a few bootstrap binaries) + a bunch of "pseudo packages"
representing target binary packages -- these would have dependencies
on the source packages. We have compilation dependencies at this stage.
You pass this information to pkg-order - it sorts out all the dependencies,
not caring what type they are. Then a script takes the output and
starts installing things as prescribed by pkg-order. When it says to
install a source packages or a binary package, just use "dpkg -i". When
it says to install a "pseudo-package", build it from source, and install
it -- now the dependencies have changed so you have to call pkg-order
again and iterate (we lose compilation dependencies after each compile).
In the end, if no errors occur and you don't have unresolveable circular
dependencies (which pkg-order will detect, I think) -- you should have
no "pseudo packages", as they all will have been replaced with binary
packages. You will not have any more compilation dependencies to the
source packages, so you can get rid of them as well.
Cool, eh? A true blue algorithm.
> [Source package overwriting problem]
> > This is only a problem in the rare situation where you upgrade a source
> > package while in the middle of building a package.
>
> Why? Are you insisting that the user "make clean" before installing the new
> package? Or will you rm -r the entire directory from the postrm script?
You've really confused me. I don't think you understand the build process
at all.
Please try the following:
$ dpkg -i src-deb-hello_1.3-1.1_all.deb src-orig-hello_1.3-1_all.deb
$ sudo make -f /usr/src/debian/src-deb-hello/Makefile binary finaldebdir=.
That will make you a .deb file.
If you want to hack on the src-deb-hello source, you can either hack
on it in the /usr/src/debian/src-deb-hello/ directory. Or more likely,
you will want to use dpkg-deb --extract and install it somewhere else.
I imagine there will be a simple script to create source packages - but
that doesn't exist yet. Just create a directory structure, copy the
source and run dpkg-deb --build by hand for now. This only takes a minute
or so to do anyways. It would be easy to do.
> > I doubt that it is going to be a common problem. Even so, a simple way
> > around it would be to declare a dependency for the unpack rule in the
> > Makefile to /var/lib/dpkg/info/<packagename>.
>
> This does not take care of removing source files that have been removed
> from the archive since the last version, and any generated files.
That would be the job of the auto-compilation system, which this isn't.
This is just an improved (I think) packaging format, that's all. But I
think it is definitely a part of the puzzle that was missing in order for
auto-compilation to work. Fortunately, I think pkg-order might just be
the other piece, and the rest is trivial.
Cheers,
- Jim
Attachment:
pgpo5CjQ1Z2en.pgp
Description: PGP signature