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

Re: source dependencies



On Fri, 18 Jul 1997, Andreas Jellinghaus wrote:

> hy.
> 
> we should implement source dependencies as soon as possible.
> the easiest way is, to add a Source-Depends: line to all control files,
> and change the scripts to add this information to dsc and changes files.

100% agreed.

> one part of source dependencies are programs and header files needed to
> compile. so we should start with creating a list, what we consider
> alway available (gcc, binutils, perl, awk, bash, libc-dev, make,
> fileutils, textutils, findutils, kernel-headers). 

Ok.

> so we will list most *-dev files, and other utilities (debiandoc-sgml,
> flex, yacc, bison). we should either have one of the lexx and yacc tools
> in the default set, or use a virtual-package-name for that (if we don't
> have one yet).

How are you going to solve the debian-policy/debiandoc-sgml dependency,
for example? I think debiandoc-sgml has to be _installed_ in order to make
use of it. But this requires "sgml-base"... Do you already have a solution
for that?

> the second part of source dependencies are needs for source code of
> other programs. my proposal is : list these with the prefix "source:" in
> the source dependency list. the program should access the source of the
> other package as "../package/" 
> (so we need a symlink package -> package-version").

What about removing the package-version of the directories name in this
case? I don't think we need the version number here. (We could make a new
option to dpkg-source that's used for autocompiling the distribution.) 

> should we have virtual package names with this second part ?
> we should allow them, but only for depending on one program with several
> version numbers (e.g. depend on kernel-source). in this case the
> maintainer of this packages should somehow rule what version is used.
> (other virtual dependencies make no sence to me).

I don't see a reason for virtual packages. I think the maintainer should
define the _exact_ package which is needed for compiling his/her package.
I don't think it's wise to compile a program with bison one day, and with
byacc the other day.

> can someone please look at the dpkg* tools, whether they need changes ?
> (i don't speak perl).

Klee, what is your status about revising the source packages? I'd suggest
to add source dependencies next time you make a major change.

> isn't the deity team working in that direction ? can someone give us a
> status report on that topic.

AFAIK, deity is another topic--no connection to a new source package
format.

> in my opinion we should decide real soon now, if we want source
> dependencies and auto compiling for debian 2.0. and if we want, we
> should start now by building a team of voluntears to go through all
> packages and make the necessary changes in coordination with the package
> maintainers. work on this topic should maybe have it's own mailing list.

I agree that this should be done _now_, if we want to have this ready for
2.0. And since one major goal of 2.0 is two support several architectures,
this could help a lot. I'd say, let us implement this now.

> todo (in this order)
>  - make a decision 
>  - find machines (one per plattform) for source dependencies

Why a seperate machine? We should define somewhere which packages are
needed in the "base system". 

An idea: is it possible to install that "source base system" (all
compilers and stuff) somewhere, say in in /usr/src/debian, and run the
autocompilation routine with chroot /usr/src/debian ? This way, every
developer which can afford the additional disk space (I expect <<100mb)
could have that base system installed and test with it.

>  - find voluntears, create a mailing list
>  - create a policy for source dependencies and auto compiling

I think this has to be #2 after the decision. The policy issues should be
discussed on debian-devel.

>  - start auto compiling on all files in incoming and in hamm

I don't think this is necessary in that early stage. I'd say we should
provide a way, each developer can have the "source base system" installed
on his/her machine. We'll define a policy that each source package has to
apply and we'll file bug reports against the packages that do not apply.
However, limiting the installation routine to packages, which pass the
auto-compilation test, will only make development slower. (Some packages
will probably need a lot of work to make them pass the auto-compile test.) 

>  - check all packages : fix bugs in auto compiling (if there are any),
> 	add source dependencies
>  - submit patches to the developer (via the bug reporting system ?)

Yes, probably as maint-only bug reports.

>  - make non maintainer releases (if the maintainer is busy / on
>    vocation / ...)
>  - build a distribution of auto compiled packages

Why a seperate distribution? We could set up a web page, for example,
which is updated on a daily basis and which lists all packages that can be
compiled automatically. The goal for 2.0 would be to have all packages on
this list.

>  - test
>  - test
>  - test
>  - test

:-)

>  - fix bugs (if there are any left) and go back to build a distribution.
>  - go back to debian-devel. show the results. vote to switch to auto
>    compiling. if so, stop uploading binaries, replace distriution with
>    auto compiled. activate feeding incoming to auto compilers.

Why? I think we could get a consensus about this _now_. Otherwise, you
won't get the people working on their source packages.

>  - work done. 
> 
> comments ?
> 
> it's possible. it's not hard work, but it's work. it's too much work for
> two or three maintainers, but with a dozend it would but only a few
> hours of work per maintainer. 

I think we need this to support more than one architecture.


Andreas, thanks for this nice summary. 


Any comments?


Thanks,

Chris

--                  Christian Schwarz
                   schwarz@monet.m.isar.de, schwarz@schwarz-online.com
                  schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
                       
                PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
              
 CS Software goes online! Visit our new home page at
 	                                     http://www.schwarz-online.com


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: