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

Re: source dependencies



> 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.

Nobody seems to object to this, so go ahead with it.  You have my approval
as VP-Engineering.


> 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).

Agreed.


> 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).

Yup.


> 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").

I don't see a problem with this.


> 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 think virtual package names are necessary.


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

Deity is completely independant from this.


> 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 don't think fixing existing packages is the most important thing.  Start
by making auto-compiled uploads.  Set things up so that only the source
files are to be uploaded and the binary packages are generated automatically.

You'll need to find a good chuck of CPU horsepower for this, especially when
something like X11 gets changed.  You also need it to build automatically on
all the other architectures (as you've said).

Don't worry about the existing packages until you've finished dealing with
new uploads.


> todo (in this order)
>  - make a decision

Done.

>  - find machines (one per plattform) for source dependencies

First priority.  Having backup sites would also be a good idea in case
the primary becomes unavailable for some reason.


>  - find voluntears, create a mailing list

If you concentrate on dealing with new uploads, the job is greatly reduced
in total effort.  It does put the difficult part first, though.


>  - create a policy for source dependencies and auto compiling

Yup.


>  - start auto compiling on all files in incoming and in hamm
>  - 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 ?)

Yup.


>  - make non maintainer releases (if the maintainer is busy / on
>    vocation / ...)

Sticking to new uploads will alleviate this for now.


>  - build a distribution of auto compiled packages

Since a lot of things already need rebuilding for libc6, this should happen
pretty much automatically as people try to upload new versions.


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

Don't really see how much can go wrong.  As long as the maintainer uses
dpkg-buildpackage, everything should compile peachily when done automatically.


>  - fix bugs (if there are any left) and go back to build a distribution.

Let maintainers do this if you can.  It distributes the load much better.


>  - 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.

I think this can be done as soon as auto-compiling is working.  You'll
have to deal with the occasional exception, though.


>  - work done.

Never happens!  <grin>


> we have enough time to do this for debian 2.0, if we start soon.

Go ahead and start.

                                          Brian
                                 ( bcwhite@verisim.com )

-------------------------------------------------------------------------------
               Friends are relatives that you make for yourself.



--
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: