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

Re: just wondering...



On Thu, Feb 19, 2004 at 05:41:14AM +0100, Frank Lichtenheld wrote:
> On Wed, Feb 18, 2004 at 07:49:18PM -0800, Edward S. Peschko wrote:
> > 
> > 
> > looking through the sources file, and just wondering *ahem* -- 
> > exactly how does this work?
> > 
> > For example - 
> > 
> > imagemagick has a dependency of libpng2-dev.
> > 
> > However, there is no package entry for libpng2-dev inside sources.
> > 
> > There is however, a 'Binary' entry of libpng2-dev under the Package heading
> > of libpng2. 
> > 
> > Is it true that these are synonyms for each other? If so, why? Why not 
> > combine the binary and package entry into one header?
> 
> The Debian policy has the answers to all your questions:
> http://www.debian.org/doc/debian-policy/

no, it doesn't.

I surmised that the Binary tag was generated from source packages - 
my question is, why the complexity? Why bother with having multiple synonyms for 
the same package?  Why not just have a source package name? 

Example: perl generates

perl-doc
perl-suid
libcgi-fast-perl
perl-debug
libperl5.6
libperl-dev
perl-modules
perl-base

and perl.

I sincerely doubt that any of these 'subpackages' could function separately 
from each other.

It also doesn't address the omissions in the apt- system, both physical 
and logical.

Example - why doesn't the sources file and the packages file have short and long
descriptions of what the projects do?  Or a pointer back to the home page of a given
project, ie: the source where the package was found?

As for physical couldn't find packages for the following:

agetty
aspell
c-client
clear
crypt
d
db4.1
distcc
ELFIO
fontconfig
gmp
graphicsmagick
inetutils
libcharset1
libiconv
libintl
man
mktemp
mod_auth_ntsec
mod_dav
mod_php4
mod_ssl
more
naim
opengl
shutdown
which



Now don't get me wrong, all of the above may have good explanations,
but I'm sure as hell not going to get them by looking at a manual.

And I'm sure as hell not going to get into the minds of those who develop
cygwin by looking at that manual either.  That document you mention 'lays it 
out as it is', it gives no clue on *why* debian was designed in this way, 
or why certain things were omitted.

> You might also consider reading the following document:
> http://www.catb.org/~esr/faqs/smart-questions.html

yeah, I've seen this document mentioned before, read it. Its one of my 
pet peeves - I REALLY dislike its philosophy (took issue once with esr on it), 
because it discourages basic 'why' questions and can lead to atrophy in 
projects. Worse yet, it rewards such discouragement by giving an 'authority' 
to point to.

Ed



Reply to: