Re: .bashrc (ls --color=auto setting)
> Nonono. auto means: > > With --color=auto, >color codes are output only if standard output is con >nected to a terminal (tty). I know, I know... but IMO it should also check the terminal type.
Re: Bug#70269: automatic build fails for potato
On Mon, Aug 28, 2000 at 06:21:55PM +0300, Antti-Juhani Kaijanaho wrote: > On 2829T004006+1100, Hamish Moffatt wrote: > > The purists have deemed debhelper to be build-unessential. > > "The purists" happen to be the readership of debian-policy from last year. Purists happen to be whoever disagrees with Hamish Moffat. Cf. his rhetoric here with his rhetoric in the great Social Contract amendment flamewar. -- G. Branden Robinson | You don't just decide to break Kubrick's Debian GNU/Linux| code of silence and then get drawn away [EMAIL PROTECTED] | from it to a discussion about cough http://www.debian.org/~branden/ | medicine. pgpB3zO6anOyt.pgp Description: PGP signature
Re: Bug#70269: automatic build fails for potato
On Tue, Aug 29, 2000 at 11:57:32AM -0500, Manoj Srivastava wrote: > >>"Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes: > > Hamish> The package could be redone not to use debhelper. At the same time, > Hamish> the package could be rewritten not to use the C compiler. > > Hamish> Lazy programmers who require a C compiler, what is the world > Hamish> coming to? :-) > > Yes indeed, there appears to be a modicum of common sense in > play here, Even though anything can be coded in assembly, or for a > turing machine, the principle here takes into account the effort > involved. It also tries to take into account the number of packages > that would need to write in an dependency if it was not a build > essential. > > For a program written in C, a total rewrite may be required > if one needs to remove the3 dependency on the compiler; however, > helper packages are not deemed to be that hared to replace. (You do > know what your helper package is doing, don't you?) I did care at one point but don't any longer. It requires less effort to figure it out anew each time a problem crops up. Computers -> More Time. ^^ That transition point is software/tools which give me that. For the vast majority of developers tools like debhelper do that. For the other vast majority of people, C Compilers do the same thing. (You do know what your C compiler is doing, don't you?). The same can apply to any large package (the kernel, X). (In howmuch detail do you know what they are doing?). One of nice things that devolves from having "interested" people look after packages is that they can see to the details, which are important, but not to everyone. Now if only there was a distribution where people looked after packages they had an interest in. Hey! Isn't that Debian? > However, given the number of people who seem to automatically > assume helper packages, is it time to revisit this issue? I think so. > manoj > i'll fight tooth and nail any effort to make helper packages mandatory Currently 87% of all packages [0] use some build scripts (not even counting dbs -- doogie's build system -- of which some large packages; e.g. X use). Not having the helper packages included in the autobuild system appears to benefit, at most, around ~470 packages. Regards, Anand [0] Raw taken from Joey Hess's debhelper charts which can be found at http://www.kitenet.net/programs/debhelper/stats/data>
Re: Potato now stable
Hi first I'm just a debian-user, if you guys don't mind my 2 cents then here it is: I think a task packages is a bad approach to the too-many-packages problems. The organisation of the packages shouldn't be part of the dependency system, IMHO. This organization is intended to help clue-less debian-user (like me) to navigate the overwhelming debian archive and selecting the desired packages without much effort. This organisation should be implemented orthogonally to the dependency system, such as: +---+ /| | The DAG of Debian | |\ / | | packages with | | \ task view | | | dependencies as | | | project view \ | | vertices | | / \| | | |/ +---+ \ / -- functionality view A view is almost-tree structure such as: functionality>tool>ui>x11-windows-manager>sawfish | | | |-->wmaker | | | | | |-->x11-screen-saver--->xlockmore-gl | | | | | |-->gtk-engines--->gtk-engines-thinice | | | |-->www>browser>communicator | |-->server>apache | |-->command-line-client--->wget | |-->apps--->office>financial>emma |-->gnucash |-->gnumeric task--->all-python>python-core>python-base | |-->python-doc |-->python-dev>python-zlib |-->python-gdbm ... project>python>core--->python-base | |-->doc--->... | |-->libs--->... | |-->ui>... | |-->... | |->gnome>core> |-->ui->themes> |-->libs--->... |-->apps>... Selecting a group in a view will select all sub-nodes. Unselecting a node won't affect the selection of its parents. That is, the arrows in the views are group relationships and not dependencies. The sawfish package would have a new control line such as: Package: sawfish Groups: project.gnome.ui.windows-manager, task.gnome-all.windows-manager,functionality.tool.ui.x11-windows-manager Package: libncurses5 Groups: project.ncurses.ncurses5.lib,task.ncurses.runtime.ncurses5, functionality.runtime-lib.ui.console.ncurses Just my confused and naive 2 cents. L.D.
