Re: dselect updating when Debian config changes
-----BEGIN PGP SIGNED MESSAGE-----
On Wed, 15 Sep 1999, Michael Talbot-Wilson wrote:
[[[COPIED FROM BOTTOM]]]
> Thank you for the self-satisified blindness of your response.
It's things like this that make people not want to help. Try being polite.
[[[BACK TO TOP]]]
> > config files, menu entries, /etc/init.d scripts, cron scripts, and so on.
> > If there's a bug in these, wouldn't you rather have Debian release a fixed
> > version than make you keep the buggy one?
> >
> > Also, sometimes the Debian maintainers make a mistake, or realize a better
> > way of doing something.
>
> Of course. But if I have a working package that I am satisfied with, why
> in the heck should I download it again on account of someone else's
> problem?
Then put it on hold and don't download it. If a Debian package requires a
specific Debian version rather than just an upstream version, chances are
pretty good something major enough was changed by the Debian maintainer to
require that dependancy.
> > "Terrible practice"? I would think you'd like it, since it means less to
> > download if you don't want everything the author includes.
>
> I'd like to hear of 20 examples in which it is really needed. A few
> people may want to selectively install bits of the author's package.
> But most authors packages are not really that badly planned. It is a
> terrible, terrible thing that Debian does this.
And i'd like to hear why you claim it's a "terrible, terrible thing".
Here's an example of this for you: Xemacs. It has compilation options for
'normal', mule, and canna-win (for supporting international character
sets). But the Debian maintainers don't want to force everyone to have
canna-win if they'll never use it, not to have 'normal' when they need
canna-win. So they offer 3 different binary packages. But all these have
many common files, the only real differences are the ones that depend on
mule/canna-win. So they have the xemacs-bin and xemacs-support packages to
hold these, saving space on the mirrors and saving download time if you
ever change binaries. Then there's the xemacs-supporttel package,
containing the files that a normal user probably wouldn't need some people
might. Then there's the emacsen-common package that contains the files
required by all emacsen, xemacs or emacs or whatever. Or would you really
want everything redundant stuck in one package?
Here's a second example: libraries. If you're not a programmer, you
probably won't need the development header files or the documentation, so
these are split into a -dev package. Regular users need download only the
libraries themselves.
Want a third example: large documentation. There's people who already own
the printed books, or who've been using the program for 10 years and don't
need the online docs. So why make them download 32 megs of tutorials and
such?
Want more? Libraries, part 2. An author writes a useful program, and
builds it in such a way that you can link other programs into its shared
libraries to use the functionality. What if someone wants such a program,
why make them download the original app as well? So the library gets split
off to facilitate this.
Perl. perl-...-base is the bare minimum, more or less what's included in
the installation floppies so that you can bring up the entire system. Then
there's perl-... that contains the full installation, perl-...-doc for
people without the Camel book and other references like that,
perl-...-suid for running suid perl scripts (some may not want to open
this security hole, so it's split off to make removal easy). Then there's
the millions of -perl libraries.
Manpages. If you're not a developer, you don't really need sections 2 and
3, so these are kept in a separate package. More saving on the download
time.
Kernel. Some people keep their own sources, why make them download the
docs and sources and such when they already have them?
non-free. Some software has extentions in the author's package that are
non-free, although the rest of the app is free (example: gif support).
Some people oppose using any non-free software, so these sections are
split out.
X. Some apps can work perfectly well in the console, and take full
advantage of X as well if it's available. But if everything was lumped in
one package, you'd have to have X installed to satisfy the dependancies.
So Debian splits the X stuff into a separate package, so the console
section can be downloaded and installed without need for X.
> > Possibly you told it not to upgrade those critical packages, and then
> > upgraded something those packages depend on. Since you said not to upgrade
> > them, they might be marked for removal instead.
> >
> > This could especially happen with perl or libc6, since nearly every
> > package depends directly or indirectly on them.
No response?
> > As a final note, you may want to stick with slink instead of following
> > potato (as i assume you're doing). Since potato is in development, you'll
> > see many packages being upgraded as they're debugged. In slink, the stable
> > release, things are only upgraded to fix major security holes and the
> > like. You could even order the CD then, and save yourself almost any
> > downloading fees.
>
> You're joking. Sure it's potato. That is not the problem. It's not
> feasible to have a Debian distribution installed because software can be
> upgraded?
Are you missing the point on purpose? You complain about having to
download so many upgrades. So use the stable distribution, which doesn't
have so many. How is that suggestion a joke? You are the one who seems to
think downloading upgrades isn't feasible.
- --
finger for PGP public key.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBN9/r/b7M/9WKZLW5AQFvHgP/XrLRxJ8wPL0x+FlGw8jUTAddWQ6i1zos
+2DZEoe3nVRNMWudPDvzo0QMYxhKpFfipQCfW0JZdlNP9UW0kWx5QLPKxRS9HMZO
OnlVRfkOsjDiu11ZRmaJhV/VcSMyD3S0iDjYTx0ZBjfceVKJXp7XPm8k7T6Ckp2k
qePGfIxAwDA=
=guDk
-----END PGP SIGNATURE-----
Reply to: