Subject: Can we reorganise the "devel" dir, please?

From: [email-masked]
Date: Sun, 14 Jul 96 10:24 EDT

There is _way_ too much stuff in binary-.*/devel; I currently see 89 packages
which is roughly a fifth of _all_ packages.

May I propose that we split the directory into
	devel			for linux and kernel compilation
	programming		for all those other languages and tools

That would make it easier for us to navigate, and for newbies to figure out
what the hell they need in order to roll their own kernels.

-- 
Dirk Eddelb"uttel                             http://qed.econ.queensu.ca/~edd

---

From: "James A. Robinson" <[email-masked]>
Date: Sun, 14 Jul 1996 18:49:26 -0400

> 	programming		for all those other languages and tools

Or perhaps
			kernel
			devel
			programming

and move the *doc* files into the docs directory?  I would prefer
better words to devel and programming, but I can't really think of any
off the top of my head...

Jim

---

From: Christian Linhart <[email-masked]>
Date: Mon, 15 Jul 1996 08:44:54 +0200 (MET DST)

> > 	programming		for all those other languages and tools
[...]
> off the top of my head...

Maybe something like

devel-tools	general development tools such as make, rcs, indent, gdb, ...
kernel-devel	Development tools specific to the kernel
libs-runtime	Runtime libraries
libs-devel	Development libraries
programming	Compilers, interpreters 

Or should we start to use multilevel sectioning ?
Such as e.g.

devel/tools
devel/kernel
devel/libs
devel/runtime	Maybe this should go elsewhere
devel/lang

Or grouped by programming language ? 
Where each directory contains compilers, interpreters, development libs
and maybe runtime-libs.
e.g.

devel/tools/	No language but general tools
devel/tcl-tk/
devel/c++/
devel/fortran/
...

-Chris

--
Christian Linhart <[email-masked], [email-masked], [email-masked]>
Student of Computer Science at Salzburg University (Austria/Europe)
get my PGP public key with "finger -l [email-masked]"

---

From: [email-masked] (Kai Henningsen)
Date: 15 Jul 1996 09:08:00 +0200

> off the top of my head...

An option might be sorting for languages, and a place for non-language  
stuff.

MfG Kai

---

From: "Brian C. White" <[email-masked]>
Date: Mon, 15 Jul 1996 10:00:38 -0400

>         programming             for all those other languages and tools

I kind of like "devel" for all development tools, but there are other
things in there as well.  Here is a quick list of things I would think
should belong elsewhere:

CGI-modules-2.75-3.deb@			run-time lib
boot-floppies-1.1.1-7.deb		system devel, but not program devel
dchanges-3.3.deb@			ditto
ecc-1.35-1.deb				utility, not devel tool
gmp-1.3.2-2.deb				run-time lib
j1-7-7.deb				interpreted lang, like perl
kernel-headers-2.0.0-0.all.deb		system devel
kernel-source-2.0.0-0.deb		system devel
libc4-4.6.27-15.deb			run-time lib
libg++27-2.7.1-2.deb			includes run-time lib
libident-0.17-1.deb			run-time lib
libobjects-0.1.19-1.deb			run-time lib
libwww-perl-5.00-1.deb			run-time lib
m4-1.4-2.deb				general macro preprocessor
perl-5.002-10.deb			interpreted lang, required package!
perl-suid-5.002-10.deb			interpreted lang
perl-tk-b11.02-2.deb			interpreted lang
python-1.3-3.deb			interpreted lang
slang-lib-0.99.23-1.deb			run-time lib
strace-3.0-5.deb			useful system utility
tcl74-7.4p3-3.deb			run-time lib
tcl75-7.5-1.deb				run-time lib
tclX-7.4a-p2-1.deb			run-time lib
tk40-4.0p3-3.deb			run-time lib
tk41-4.1-1.deb				run-time lib

I'd like to suggest a "libs" dir for the run-time versions of the shared
libraries.  A person who isn't going to be doing any program development
should be able to exclude the "devel" directory completely.  No packages
from another section should depend upon development packages to run.

                                        Brian
                               ( [email-masked] )

-------------------------------------------------------------------------------
    In theory, theory and practice are the same.  In practice, they're not.

---

From: Christian Hudon <[email-masked]>
Date: Mon, 15 Jul 1996 11:02:48 -0700 (PDT)

> devel/tools/	No language but general tools

Hmm. Can the dselect/dchanges/dinstall handle multilevel sections?

How about a mix of the first and last suggestions? Something like:

devel-tools    general development tools
libs-runtime   runtime shared libs.
libs-devel     header files, etc. needed to develop with libs in libs-runtime
programming-c  
programming-tcl
programming-perl
programming-python
...

But most of the programming-* categories would be almost empty. How about
then

...
programming-c
programming-whatever-other-languages-have-lots-of-.deb-files
programming-misc

<shrug>

I don't care that much about the final layout, except for the
'libs-runtime' category which is something I strongly feel we should have.
That way, people can install all the .so libs with one keystroke in
dselect, instead of hunting around.

And I don't think the 'kernel-devel' category is a very good idea...
Because a) the kernel is a moving target; who knows what other stuff Linus
and co. might be using to compile the kernel 6 months or a year from now?
b) looks like this problem will be solved by the new source package
format, with the source dependencies.

   Christian

---

From: Lars Wirzenius <[email-masked]>
Date: Mon, 15 Jul 1996 23:32:49 +0300

[ NB: I read the list.  Don't CC replies to me.  I pay for my PPP.  Thanks ]

> which is roughly a fifth of _all_ packages.

I agree about the need, although I'd suggest a different split.

I invite comments on the following suggestion:

	devel-base	
		enough to compile the kernel, and some other typical 
		programs
			
	devel-lang
		implementations of programming languages, 
		language implementation tools
		
	libraries
		runtime library packages (needed for running programs
		using the library)
	
	devel-libs
		development library packages (needed to compile the
		programs using the library)
		
	devel-tools
		other programming tools
		
My personal mirror isn't quite complete, but the 68 packages I do have 
would fall into the above categories something like this (some of this
may have to be discussed):

	devel-base:
		bin86 binutils gcc libc5-dev make ncurses3.0-dev 

	devel-lang:
		bison byacc cpp flex gcl gclinfo gmp guile j1 intercal m4 
		p2c perl-debug perl-suid perl-tk perl python tcl74-dev tcl74 
		tcl75-dev tcl75 ratfor77 tk40-dev tk40 tk41-dev tk41 tclX 

	libraries:
		libc4 libg++27 libobjects libwww-perl slang-lib 

	devel-libs:
		electric-fence libc4-dev libc5-dbg libc5-pic libdb1-dev 
		libgdbm1-dev libident libreadline2-dev ncurses3.0-pic 
		slang-devel 
		
	devel-tools:
		c2man cvs cflow ddd-smotif gdb gettext gnat indent dlltools 
		expect pmake rcs strace xxgdb ecc id-utils ilu dld 
		
Unclassified remain:

	boot-floppies (shouldn't this be in admin?)
	xwpe (shouldn't this be in editors?)

Someone with a full mirror might want to add the missing packages.

Other comment: should libobjects be divided into runtime and development
packages?  It seemed  to have both kinds of stuff.

---

From: [email-masked] (Emilio Lopes)
Date: Mon, 15 Jul 96 20:52 EST

>>>>> "BCW" == Brian C White <[email-masked]> wrote:

BCW> m4-1.4-2.deb				general macro preprocessor

text section?

Emilio.

-- 
                 Emilio C. Lopes <mailto:[email-masked]>
               Instituto de Fisica da Universidade de Sao Paulo
             Caixa Postal 66318, 05389-970 Sao Paulo - SP, BRAZIL
              Phone: (+55) (11) 818-6724 (Voice) / 818-6715 (Fax)

---

From: Dale Scheetz <[email-masked]>
Date: Tue, 16 Jul 1996 08:03:57 -0400 (EDT)

> BCW> m4-1.4-2.deb				general macro preprocessor
Nope, this falls in the same class as cpp, and the other preprocessors. It
is not a text processor like psutils...

Later,

Dwarf

------------                                          --------------

aka   Dale Scheetz                   Phone:   1 (904) 877-0257
      Flexible Software              Fax:     NONE 
      Black Creek Critters           e-mail:  [email-masked]

------------ If you don't see what you want, just ask --------------

---

From: Ian Jackson <[email-masked]>
Date: Tue, 16 Jul 96 15:31 BST

Christian Hudon writes ("Re: Can we reorganise the "devel" dir, please?"):
...
> Hmm. Can the dselect/dchanges/dinstall handle multilevel sections?

dselect and dpkg can.  dpkg-scanpackages can too, but it seems to me
that using hyphenated rather than slash-separated names is probably
better.

I think that we need to think about what kind of packages people may
choose to install or not to install.  Remember that we already have a
priority classification scheme for saying whether something is
`important' or `standard', so there's little point in separating
devel-base and devel-extra or whatever.

Useful categories might be scripting languages (which are useful even
if you don't write the scripts yourself), shared libraries (which
ought not to be in devel at all IMO), and C/C++ development vs. other
languages.

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Tue, 16 Jul 96 15:35 BST

> BCW> m4-1.4-2.deb				general macro preprocessor

I think this should count as a programming language or script
interpreter.

Ian.

---

From: Chris Fearnley <[email-masked]>
Date: Tue, 16 Jul 1996 17:35:05 -0400 (EDT)

'Lars Wirzenius wrote:'
>		enough to compile the kernel, and some other typical 

No, dselects' section field covers this.

I haven't seen a suggestion I like yet ...

-- 
Christopher J. Fearnley            |    Linux/Internet Consulting
[email-masked], [email-masked]       |    UNIX SIG Leader at PACS
http://www.netaxs.com/~cjf         |    (Philadelphia Area Computer Society)
ftp://ftp.netaxs.com/people/cjf    |    Design Science Revolutionary
"Dare to be Naive" -- Bucky Fuller |    Explorer in Universe

---

From: Lars Wirzenius <[email-masked]>
Date: Wed, 17 Jul 1996 12:28:13 +0300

> that using hyphenated rather than slash-separated names is probably

If we start creating subdirectories of devel, we should move all packages
to the subdirectories.  It is too difficult to find subdirectories among
a couple of dozen packages.

> devel-base and devel-extra or whatever.

It is my impression that many people will only use gcc for compiling 
the kernel.  I think we should make it easy to download just the essentials
for that.

> Useful categories might be scripting languages

I'd prefer to call them interpreters.  For example, Lisp and Python aren't
scripting languages.

> shared libraries (which ought not to be in devel at all IMO), 

I agree.