On 15/01/2018 15:02, LM wrote:
> On Sun, Jan 14, 2018 at 4:20 PM, Damiano Verzulli <damiano@xxxxxxxxxxx> wrote:
>> That's _NOT_ what I was suggesting, nor what apt-mirror is for.
>
> Thanks for the clarification. Doesn't sound like it's what I'm
> looking for at the moment. Sounds useful for other situations.
>
Ok. Got it.
> Hopefully we can just agree to disagree.
Sure :-) Actually I'm really happy to discuss about such "technical"
issues here, in this "gentle", "relaxed" and "civil" way. Hope the same is
for you :-)
At least... until someone else let me notice that I'm going "off-topic" :-)
But until then, again, I'm happy to discuss :-)
As for my point "pro-package-managers", I choosed to get slightly deeper
stressing it just to ensure that our two (different) opinions about
package-management are "balanced". You know: there are hundreds of people
reading us, here (hopefully!) and... I didn't liked the idea that they
received a "one-way" message :-)
> [...]
> However, in my personal
> experience, I've broken the system using the package manager more than
> once.
> [...]
> I guess your experiences with packages and package management tools
> are very different from mine.
I think that "package management" (as a "concept") is a fundemental concept
about 99% of Linux distributions, strongly contributing in differentiating
Linux from Windows (where, by far, a package manager is absolutely
missing!). As such, it could be helpful for people involved in Linux at
various levels, to get an idea about its role, and its different behaviours
(RPM, DEB, APT, YUM, DNF, etc.)
Having said that, I also want to add that IMO, figuring out what a
"package" is, is not exactly an easy step. It requires some technical
skills (that I'm sure you "own"... but I'm also sure lots of people are
missing).
That's why, again, I think that discussing about these concepts here is
useful :-)
> I make a lot of my own builds from scratch using the source.
I started compiling source code (kernel, BTW) in 1996. Before 2000 I was
able to build a customized RedHat Kernel (with "custom" modules) in a RPM
package to be distributed among tens of _DIFFERENT_ Linux boxes (different
RedHat releases). Afterwards I "jumped" to the DEB package management, as
well to the APT over-layer. Lately I've been (slighly) playing with YUM and
now I'm going to understand the trickies about DNF. Lots... and lots... and
lots... of technicalities, well beyond the average-users capabilities (and,
actually, well beyond the capacity, for me, to "catch" all the gory details).
I was astonished, three/four years ago, when I discovered NPM (a "package
manager" for NodeJS [NodeJS is a "Javascript framework"]). Some year before
I discovered PEAR, a package manager for PHP.
Even if with a sort of "raw" style, PERL has its own package-manager (CPAN)
and the same apply to Python (as far as I know; as I don't know Python at
all, unfortunately).
Even in other context, like "TeX" or "LaTeX", the concept of "Package" (and
"package" resolution) play an important role.
This, _NOT_ to say that dealing "only" and "directly" with source code and
building our own-style packages is WRONG. I only want to stress the concept
that given the incredibly "high-level" of complexity of software
development, having something that "help us" in keeping track of the
correct relationship between "our" code and the whole stuff of underlying
libraries... are getting an always increasing and time-consuming and
complex task. That's the very reasons, for package manager, to exist... and
to support "developers".
At exactly the other side, when I'm working with Arduino, I really _DON'T_
feel the need of a package-manager at all: its extremely small-footprint
gives absolutely no space to complexity and, in such case, the programmer
is absolutely able to self-manage the 100% of complexity of his own code.
Cheers,
DV
--
Damiano Verzulli
e-mail: damiano@xxxxxxxxxxx
---
possible?ok:while(!possible){open_mindedness++}
---
"Technical people tend to fall into two categories: Specialists
and Generalists. The Specialist learns more and more about a
narrower and narrower field, until he eventually, in the limit,
knows everything about nothing. The Generalist learns less and
less about a wider and wider field, until eventually he knows
nothing about everything." - William Stucke - AfrISPA
http://elists.isoc.org/mailman/private/pubsoft/2007-December/001935.html
Attachment:
signature.asc
Description: OpenPGP digital signature