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

design of an apt-src program



This is very incomplete but I think it explains the basic ideas.

apt-src design

Goals:

- To eliminates the need for *-source debs.
- To support source build-deps.

Requirements:

1. Simple command to install a source tree.
2. Simple command to remove a source tree.
3. Customizable source tree locations. Put it wherever you want it.
4. A way to query for the location of a source tree, so software that needs
   to include stuff from it to build, or build parts of it, can work.
5. An upgrade command that updates the source trees, ideally first checking
   for local modifcations to each and aborting if so (or generating forward
   patches).
6. Use by regular users, but also usable by root to install in canoical
   locations (/usr/src).
7. Sources installable from CD, etc.
8. An interface familiar to anyone who knows apt.
9. A way to list available source trees and their locations.
10. Handle source dependencies amoung source trees; build-dep satisfaction on
    tree install and upgrade.
11. Support auto-rebuilds on upgrade?

Source dependencies:

I'm not yet sure of all the ways that source trees can depend on each
other. -I/path/to/other/source tree is a likely one. Kernel module source
trees depend on a _built_ kernel source tree, and should be rebuilt when
the kernel tree is rebuilt to keep in sync. What else?

Some interesting packages to look at in research this include:
	busybox-source-0.60.0
	cmucl-source
	mpe-source
	ocaml-source
	toolchain-source
	sawfish-lisp-source
	tetex-src?
	mindterm (an edge case; the binary package includes full source for
	          legal reasons..)
	pine (only source package avilable; pine-tracker; etc)

Interface & implementation:

I thought about just using CVS, which would give 5 for free quite nicely.
Unfortunatly, our sources aren't in CVS, and such a repository does not seem
to be happening. Also, conflicts with point 7. Plus people find it hard to
use.

Let the command be "apt-src". It would support these actions:

apt-src install foo
	apt-get source foo into dir under current directory. Possibly
	rename directory to remove version number.
	
	If foo is already installed here, upgrade it instead.
	Check that build-deps are satisfied (via apt-get build-dep foo).
	Check that source-deps are satisfied as well; if not install them
	recursively. 
	
	(Would sources installed by root satisfy such source-deps?
	They could only if the depended upon trees are used read-only.)

	Note that as with apt-get source, this should allow use of "apt-src
	install foo=1.1" to get version 1.1 of foo.

	It would be useful to be able to make it install a source tree into
	a standard directory, instead of the current one, sometimes.

	Support a --build to make it compile the tree after download.
apt-src upgrade
	upgrade all sources installed by this user, checking and resolving
	build-deps and source-deps

	Support a --build for compiling all updated sources.
apt-src remove foo
	remove source tree for foo, checking source-deps of source trees
	installed by this user first.
apt-src list
	list all installed source trees; including their location and
	version
apt-src treedir
	output the directory a tree is unpacked in

It will need a status file like thing to list installed source trees, and
their location and version.

Since this can be used by regular users, this needs to be stored in user
home dirs for regular users ~/.apt-src/status ? For root, it can be in
/var/

If the file includes some kind of a file list of each tree, apt-src can
detect, on upgrade, if the tree has changed, and abort or prompt or
generate diffs or whatever works well. It might need to debian/rules clean
the tree first. Something more concentrated than a full file list would be
nice. md5sum?

-- 
see shy jo


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: