Re: prompt to create non existent directory.

[<tomas@tuxteam.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Nov 02, 2017 at 03:25:18PM +0100, Emanuel Berg wrote:
> t wrote:
> 
> > Because for ~98% of those packages I want
> > "tried and tested" and not "latest and
> > greatest". The other 2% I care specially for
> > I put more admin work into (and bear with
> > ocassional breakage).
> >
> > [...]
> > 
> > It's still one gadget per app to take care
> > of. I don't feel like feeding thousands of
> > gadgets, even if they are shell scripts.
> 
> The issue with the "~2%" is that the repo's SW
> is too old or sometimes unavailable.
> 
> Why can't this be available without doing it
> 100% manually? Well, it can, and that's what
> those gadgets do! Why not for Emacs as well?
> We have [M]ELPAs for additional software.
> Why is it such a far-fetched idea upgrading
> Emacs in a similar manner, if it can be done,
> as I suspect it can?

These gadgets exist. Perl's CPAN, Python's PIP,
Emacs's (M)ELPA, the list goes on.

Thing is, that they all need a "base" infrastructure,
provided by Perl, Python or Emacs, or whatever.

Note that Perl, R (and Python, I assume) do
run the C compiler in their gadgets (or whatever
else) if needed: so the split you are construing
(gadget vs compile from source) is a rather
artificial one: gadgets do orchestrate the
compilation from source since times immemorial.

Packagers are no idiots, believe me.

And as to bridging -- look at how many Perl
packages are maintained by a rather small team
at Debian. Why? Because they do leverage Perl's
package system (CPAN) to semi-automatically
derive Debian packaging. Again, packagers are
no idiots. Just hang around in the Debian perl
mailing list and you'll see.

What they do, and I appreciate that to the
utmost, is to make sure all versions of things
in there play well with each other (and with the
rest of the system). *This* is the hard problem,
not "compiling from source".

The "solutions" touted these days, packaging
each application into its own little world and
letting them talk to each other over http is,
in my eyes, pretty disgusting.

The only (to me) interesting innovation on
the horizon is perhaps the NixOS/Guix philosophy,
which makes it possible to have different versions
of things in parallel, depending on cross-dependencies.

Only time will tell whether this leads to
"software dust" where each little piece has
an own world, with its own libc version, etc.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAln7L00ACgkQBcgs9XrR2kbp5gCfVDFrK2kXrQWTjEJVt/5JCvA8
CWQAn1iLEbAUH1BAQA39YiWgisDW0XnQ
=zQdv
-----END PGP SIGNATURE-----