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

Re: source dependencies



> > 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 primary goal of source dependencies is to decide whether it makes
sence to try to compile something or not. if source dependencies are not
fullfilled, it's useless to try. an autocompile will take care of source
dependencies, and only queue packages with fullfilled dependencies.
for source packages it can try to take care of that himself by
extracting the sources needed for that program. 

for other program, it could maintain a list of programs needed for
compiling, and the admin of the machine (or an automatic script), could
install these (and remove them the next day).

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

ln -s $package-$version $package
mv $package-$version $package

it doesn't matter which way we use, the result is nearly the same.
using the first method shows also the version of a source package, so i
prefer it.

> (We could make a new option to dpkg-source that's used for
> autocompiling the distribution.) 

no, i don't think we need that. i'm not using dpkg-buildpackage, and my
script anyway has to do some actions. i will rewrite the whole script
someday and add more stuff like multiple compiling sessions at one time
etc, and then i will implement that.

> 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.
yes. that's what i say. but he should not specifiy the version used for
compiling. and for packages with version'ed names (like tcl or
kernel-source), we need this pseudo virtual packages.

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

i only want to make sure that we don't hinder them in their work.

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

implementation is not a big problem. all i need now is access to a
networked machine with hamm installed (and we need to complie some
programs as glibc, if they are libc5).

a source mirror could help, but i can also implement some way of sending
packets from master to the machine, and back.

with that i can start compiling everything as glibc. but looking at all
pakages is too much work for one person. that will need a team.

the thrid thing we need is 700 MB for the auto compiled version of hamm.


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

my own machine is only a p120, and i have to sleep, so it will not run
at night. and i don't want to transfer the whole debian to my machine
and back, so we need some machine on the net. i don't know if we can use
master for that.

and we need one sparc to compile as sparc, on alpha for compiling as
alpha etc.

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

we don't need that. all i need is one user account (ok. better : two).
compiling is done as user (we use fakeroot).

> This way, every developer which can afford the additional disk space
> (I expect <<100mb) could have that base system installed and test with
> it.

he can use his own computer as test system. of course a seperate test
system will make it easier to find unlisted dependencies. but i don't
think it's that hard to detect them, and i don't expect all source
dependencies to be correkt with the first try.

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

why slower ? i was not talking about stoping the normal way we use now.
it was only meant as a paralell test system to detect errors.

> (Some packages will probably need a lot of work to make them pass the
> auto-compile test.) 

that's why i want to start auto compiling as soon as possible.
i have already tried to compile 333 packages, and so i have 333 log
files available for examination. 

but i used the old debian 1.3.0 bo cdrom, and there are already some bugs
fixed. so i'm searching for a networked machine, where i can start
working.

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

only for testing. we can't find bugs in the automatic build process, if
we don't store out files somewhere, so we can compare.

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

i'm searching for the fastest way to get some machine, where i can start
auto compiling. developing a policy and that can go paralell. i don't
want to delay. and if i can say "hey, i have compiled most hamm
packages, and lots bugfixes and patches ready to submit. auto compiler
is working, you can download a whole auto compiled distribution at ..",
i doubt that many people will not like it.


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

that's what i want. i will support any architecture, if i can get an
account on a machine somewhere. i'm no expert for porting, but i can
reduce the work of porting to programs, that don't compile clean.
and with fixing bugs found while compiling on a i386, will also make it
easier for the other plattforms.

some statistics :
packages automatic compiled now :
acct_6.2-4 acm_4.7-5 adduser_3.2 adjtimex_1.3-2 ae_962-14 alias_2.3-1
anacron_1.0.2-1 apmd_2.4-5 autoconf_2.12-1 autolog_0.34-2 automake_1.0-4
base-files_1.3.5 base-passwd_1.3.1 bash_2.0-3 bc_1.03-14
berolist_2.3.5-1 bin86_0.4-3 binutils_2.7.0.9-3 bison_1.25-4
bridge_0.1-4 casio_2.01-2 cflow_2.0-9 compface_89.11.11-9 courtney_1.3-1
cron_3.0pl1-38 cti-ifhp_1.3.1-1 cweb-latex_1.1.1-2 cweb_3.4g-5 ddd_2.1-3
debian-cd_0.1.4 debianutils_1.5 dftp_3.0-3 diff_2.7-13 dist_3.70-1
dlltools_2.17-13 doc++_3.0-1 doc-iana_1997.05-1 doc-linux-es_97.03-2
doc-linux-it_97.02-1 echo-linux_96.12-1 ee_126.1.89-4 eject_1.5-1
elvis-tiny_1.4-3 exmh_1.6.9-4 fdflush_1.0.0-7 fetchmail_3.8-0
file-rc_0.4.1 flex_2.5.4-2 freelip_1.0-2 fte_0.45-2 ftplib_1-5
gclinfo_2.2-4 gdb_4.16-6 genpower_1.0.1-3 gmp_2.0.2-2 gnats_3.101-2
gnugo_1.2-2 gnushogi_1.2p03-3 grep_2.0-11 gstep-base_0.2.12-1
guile_1.0-1 gzip_1.2.4-15 hello_1.3-13 hpscanpbm_0.3a-5 icmake_6.21-1
indent_1.9.1-16 inews_2.1-2 info2www_1.2.2.9-5 intercal_0.15-2
jargon_4.0.0-2 java-lex_1.1.4-1 jedsl_0.98b-1 joe_2.8-7 joystick_0.8.0-1
kbd_0.92-3.1 kernel-package_3.28 knews_0.9.8-5 lee_1.1-2 lesstif_0.76-1
lftp_0.10.0-1 lg-base_17-1 lg-issue01to08_1-1 lg-issue09_1-1
lg-issue10_1-2 lg-issue11_1-1 lg-issue12_1-3 lg-issue13_1-2
lg-issue14_1-4 lg-issue15_1-4 lg-issue16_1-3 lg-issue17_1-1
libdb_1.85.4-3 libdnd_1.0-4 libelf0_0.6.4-5 libgdbm_1.7.3-19
libgsm_1.0.10-2 libjpeg_6a-4 libpcap_0.3-1 libtool_0.7-3 lilo_19-2
loadlin_1.6-2 lprng_3.2.1-1 m4_1.4-6 mailtools_1.06-3 make_3.75-4
man-db_2.3.10-38 man2html_1.5-13 manpages-fr_0.1-5 manpages_1.15-4
mbr_1.0.0-5 metamail_2.7-21 mhonarc_1.2.3-3 mime-support_2.12-1
mimedecode_1.8-1 minicom_1.75-2 mirror_2.8-9 miscutils_999.0-1
modemu_0.0.1-1 modutils_2.1.34-5 moxftp_2.2-1 nasm_0.93-1 objpak_1.1.1-1
p10cfgd_1.0-5 pari_1.39.03-6 pc532down_1.1-3 povray-manual_3.0.10-3
pvftools_1.1.2-1 pwgen_1-5 rcs_5.7-4 shellutils_1.16-2 slib_2a6-1
sudo_1.5.2-4 suidmanager_0.6 syslinux_1.30-2 termcap-compat_1.1.0
texinfo_3.9-4 textutils_1.22-1 tkinfo_1.3-2 ucblogo_3.3-1 upsd_1.0-3
uucp_1.06.1-6 verse_0.15 vim_4.6-1 wily_0.13.33-1 x10-automate_1.00-1
xcoral_2.5-4 xwpe_1.4.2-1

auto compiling failed :
acs_021-2 adbbs_2.1-1 addressbook_0.6.1-1 alien_3.3 amd_upl102-11
axe_6.1.2-6 bible-kjv_4.00-2 biff_5.31-1 bind_4.9.5-1.4 bl_1.2-2
blast_1.1-3 blt_2.1-6 boot-floppies_1.2.18 bridgex_0.22 bsdgames_1.3-7
bsdutils_3.1.3 bulkmail_1.6-2 c2man_2.41-4 calc_2.02f-1 calctool_2.4.9-4
cfengine_1.3.19-1 cfgtool_1.5-1 checker_0.8-8 cnews_cr.g7-4
cxhextris_1.0-3 debian-policy_2.1.3.2 defrag_0.61-1 dejagnu_1.3-5
dhcpcd_0.6-1 dhcpd_0.5.14-2 diald_0.16.1-4 dialdcost_0.1 diffstat_1.25-5
dnsutils_970203-0.1 doc-debian_1.5-0 doc-linux-fr_97.05-1
doc-linux_97.03-1 doc-rfc_1997.05-1 dpkg-ftp_1.4.8 dpkg_1.4.0.8
dwww_1.4.1-1 e2fsprogs_1.10-2 efax_08a-3 electric-fence_2.0.5-3
elib_1.0-2 elk_3.0-1 elm-me+_2.4pl25ME+31-5 elvis_2.0-8
emacs-czech_3.4-1 emacs_19.34-11 emacspeak_5.0-2 exim_1.61-1
fcgi-devel-kit_1.5.1-1 fileutils_3.16-2 filters_1.2 findutils_4.1-22
fortune-mod_9510-4 fsp_2.71-7 ftpwatch_1.1 g77_0.5.20-1 gcc_2.7.2.1-8
gcl_2.2.1-1 genromfs_0.1-2 gettyps_2.0.7i-1 gforth_0.2.1-1 glut_3.3-2
gnat_3.09-1 gnuplot_3.5beta6.328-1 gpc_2.0-3 gravitywars_1.102-1
groupkit_3.2-1 guavac_0.2.6p1-1.1 hdparm_3.1-2 icon_9.1-1 ilu_2.0.0.8-2
imagemagick_3.8.2-1 imap-4_4-4 inn_1.5.1-2 innfeed_0.9.2-1
iplogger_1.00-2 iproute_961225-2 ipxripd_0.7-1 ircd_2.9.32-3
isapnptools_1.9-1 isdnlog_2.51-3 isdnutils_2.0-7 jed_0.98.2-2
kernel-source-2.0.29_2.0.29-7 kernel-source-2.0.30_2.0.30-7
lambdacore_02feb97-1 lambdamoo_1.8.0p5-2 ld.so_1.8.10-2 leafnode_1.0-3
libc_5.4.23-6 libg++27_2.7.2.1-8 libhdf4_4.0.2-3 libident_0.21-1
libnatali_1.10-3 libnet-perl_1.04-1 libnet_1.01-3 libpng_0.89c-6
libpthread_0.5-2 libtclobjc_1.1b3-5 libwww-perl_5.07-1 lincity_1.03-2
liwc_1.0-1 lpr_5.9-13.1 lrzsz_0.12b-1 luxman_0.41-1 maelstrom_2.0.4-1
mailagent_3.56-3 mailx_8.1.1-3 makedev_1.6-4 menu_1.3-2 mercury_0.6.2-1
mesa_2.2-1 mgetty_1.1.2-1 mh_6.8.4-13 mingetty_0.9.4-3 mirrormagic_1.3-4
modconf_0.2.11 mount_2.6d-1 netatalk_1.4b2-4 netbase_2.13-1
netboot_0.4-1 netcdf-perl_1.1-4 netcdf_2.4.3-5 netdiag_0.4-3
nethack_3.2.2-7 netmaze_0.81-2 newsx_0.1-1 nfsroot_0.5 nis_2.20-1
nitpic_0.1-1 nntp_1.5.12.1-1 nvi_1.76-1 octave_2.0.5-2
oldmitpthreads_0.0 oleo_1.6-8 oneko_1.1b-5 open_1.4-1 opie_2.3-1
pacman_10-4 pam_0.56-2 pcmcia-cs_2.9.5-3 pente_2.1.11-4 perl-tk_b11.02-5
perl_5.003.07-10 pgapack_1.0-6 picon-domains_97.02.21-1
picon-misc_97.01.07-2 picon-news_97.02.20-1 picon-unknown_97.01.07-2
picon-usenix_95.04.13-1 picon-users_97.02.20-1 picon-weather_97.01.07-3
pixmap_2.6pl4-3 pj-base_1-2 pj96n04_1-2 pj96n05_2-2 pj96n06_2-3
pj96n07_1-2 pj97n08_2 pj97n09_2 poeigl_1.45a-3 poppassd_1.2-5
procps_1.11.6 quota_1.55-8 rpm_2.3.8-1 sac_1.5-2 sed_2.05-12
setserial_2.12-2 sex_0.9-1 shadow_961025-2 sup_1.8-3 svgatextmode_1.4-10
sysnews_0.8-6 sysvinit_2.71-2 tar_1.11.8-11 timeoutd_1.5-1
timezone_7.55-2 update_1.2-1 util-linux_2.5-12 uutraf_1.1-1 vbox_1.1-1
visual-tcl_1.07-2 watchdog_2.1-2 wg15-locale_2-5 x10_1.05-1
xringd_1.10-4 xtel_3.1.3-1 xxgdb_1.12-9

in numbers : ok 147 failed 192   

on a p120, it takes 40h to compile all debian packages (estimated time)

andreas


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