Re: just wondering...
On Wed, Feb 18, 2004 at 10:05:57PM -0800, Edward S. Peschko wrote:
> 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?
Because some source packages generate multiple groups of installable items
of which not all will be useful to everybody. Hence, to reduce unnecessary
disk wastage, we create multiple binary packages.
> 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.
Then your doubt is misplaced. All of those packages above provide differing
functionality, which may or may not be needed in some circumstances. For
instance, I don't think I've got perl-suid installed on most of the machines
I administer; nor do I have perl-doc installed most of the time (and that's
nearly 4MB I've saved there). Similarly, not everyone is going to need
libperl-dev, and in some embedded situations you might want libperl5.6 but
not perl-base or perl-modules.
So, as you can see, splitting a source package into it's constituent
components (as binary packages) does have it's uses.
> 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?
How are these deficiencies in apt? They're "deficiencies", if anything, in
the debian/control file format (although I disagree they're even
deficiencies).
The source package location should be documented in
/usr/share/doc/<package>/copyright. The Packages file describes, oddly
enough, what the package does. If you want to know what the project which
produced the package does, you want something other than a Packages file.
> As for physical couldn't find packages for the following:
>
> agetty
That would be because there are no agetty packages.
> aspell
http://ftp.debian.org/debian/pool/main/a/aspell appears to have all the
necessary files.
> clear
> crypt
> d
> db4.1
> c-client
Another "not a package".
> distcc
.../pool/main/d/distcc
> ELFIO
Not a valid debian package name.
> fontconfig
.../pool/main/f/fontconfig
And so it goes.
> 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.
No, but you might get them by doing a bit of research.
> 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
I sincerely doubt it. You would likely get more Cygwin enlightenment if you
went and talked to the Cygwin people.
> out as it is', it gives no clue on *why* debian was designed in this way,
> or why certain things were omitted.
Certainly. However, being combative and fairly obviously clueless doesn't
help your chances of finding things out, either.
> > 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),
Namedropper.
> because it discourages basic 'why' questions and can lead to atrophy in
No, it discourages clueless questions. If you laid it all out, with "I've
read this, read that, this doesn't make sense. I'd appreciate a historical
perspective on why this was done this way" (notice the "why" in there) you'd
get an answer. Walking in with your ignorance hanging out proudly doesn't
help matters.
- Matt
Reply to: