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

Re: apt, deity, dpkg, aptitude history



in-line :-

On 26/07/2016, David Kalnischkies <david@kalnischkies.de> wrote:
> Big disclaimer: I joined the APT team roughly 7 years ago (oh my god,
> I am getting old…). That sounds like an oldtimer, but back then the
> team existed for more than a decade already. It is important to realize
> that nobody who is currently on the team started apt through. In fact,
> nobody of the current team was working at the same time with anyone who
> started apt. You are therefore not likely to get first-hand info here.
> Not even second-hand. Third hand at best, I am more like fourth hand
> really… so my responses on that matter aren't hardfacts: I could be
> lying my ass off without even knowing!
>
> If you want to know how things were back in the day for real, find
> someone from that time who is still active and interview him. You were
> at this years DebConf, perhaps you already meet the right people in
> person!
>

Dear David,
Probably but I don't know if anybody other than JAK (Julian Andreas
Klose) was there from the deity team . Also while it would have
probably possible for them to have/look at old releases and get that
data point from there but I wanted to get it more from people who are
using it, maintaining it and have their own interest to it.

I do have to confess that I took over couple of days debating within
myself whether I should ask this or not but in the end guess made the
right decision.


> On Tue, Jul 26, 2016 at 08:30:25AM +0000, shirish शिरीष wrote:
>> benign/naive idea that these tools were made by Ubuntu/Canonical and
>> only much later I came to know that it's in fact Debian which does
>> much of the work. In that sense, I would be forever grateful to
>> Ubuntu/Canonical for introducing me to the deb Universe.
>
> apt existed long before Ubuntu did, so, by definition it can't have
> created it. That said, some of the past and/or present apt developers
> were or still are at one point employees of that company.
>

That came out a bit wrong. While today I know that Ubuntu is a
downstream distribution from Debian, that time I did not and
Ubuntu/Canonical acted (in its marketing literature and even if Debian
was mentioned it was more of an afterthought therein.) as it were the
producers of all the toolings within it, hence that mis-understanding.
I guess launchpad also gives of the same notion but then I am
digressing here from the main point.

>> Coming to my question what I've been trying to figure out is when the
>> project/distribution started have repository updates and being able to
>> upgrade in-place and using which tool to do that ?
>
> Kids rejoice, its uncle Davids camping fire story time!
>
> Back in the early days there was only dpkg. You would get your packages
> from a mirror by hand and install them with it. After a while various
> scripts appeared which automated that task. The repository was growing
> and growing, so that soon you would need a tool like dselect to keep on
> top of the action. Also, the scripts got hackier by the minute, so in
> 1997 people set out to create the godfather of package management: It
> should be a GUI, replace dselect and even dpkg and its name was deity.
> Eventually it was decided that 'deity' isn't a good name, so on the 1st
> April of 1998 it was publicly announced that the project would be from
> now on called 'APT' (or Apt, or apt, or… everyone seems to have used
> a different style. As well as different things for what 'APT' stands
> for). A few days later the first version hit the archive.

I suspected the answer to be somewhat similar but didn't know I was
close to the truth or at least truth as its publicly known. I am
sufficed by this itself.

> The GUI never came to be, dselect was never directly challenged and dpkg
> remained as part of the ecosystem. In other words: An all around
> failure! apt-get, apt-cache and co which were first made as kind of
> demos for how to use the underlying libraries (from the apt project,
> too!) until the GUI surfaced became over time the product instead. Time
> passed, people come and most also go.
>
> Eventually, in a moment of apt development inactivity a project called
> 'aptitude' came to be. The goal as easy as before: Take over the world,
> replacing the old hardly maintained apt with a funky new all around
> better tool which would have a GUI this time and a better resolver.
>
> That turned out to be slightly more successful as a plan in that it
> actually produced a GUI. Still, apt survived and regained traction so
> now both apt and aptitude live together in Debian happily ever after
> with a usually loyal servant called dpkg and an ugly older stepbrother
> hiding in the dark corners of the castle called dselect.
>
>
> That is at least how I see it, but all of this story happened before
> I came here and as all good stories it avoids details for the sake of
> the story arc. I think I deserve some credit for not including a fire
> breathing dragon through…
>
>
>> Another query - I have been following apt for quite some years and
>> even though it has some limitations (safe-upgrade not being there) it
>
> 'apt-get upgrade' is there since ever and is even safer than
> 'safe-upgrade' as it only upgrades packages you already have installed.
> The aptitude command also installs new packages, but no problem, 'apt
> upgrade' does that, too. There is also a flag for apt-get to do it.
> aka: The "safe-" just means that it isn't removing already installed
> packages, not that it makes the upgrade itself in any shape or form
> safer.
>
>
>> seems it has been quite active in the last 2-3 years at least. It also
>> seems to have had an impact on aptitude development also as David K.
>> has also become a bit more active. Is my sense of things on the
>
> I don't think "that guy" became particularly more active in the last
> few years. He absolutely went from new kid on the block to evil master
> mind, but I think that was earlier already as there was no hope for him
> after 2010 (implementing Multi-Arch in APT) anyhow. As he is still
> a student with a million other (side-)projects (in reallife) time
> investments vary of course, but as objectively as I can be while talking
> about him: At times he does too much.

Agree.

> He has no direct impact on aptitude whatsoever through[0]. He doesn't
> even use it. He started it like once or twice in his life and declared
> it to complicated for himself. Between you and me, I think that is more
> his brain telling him he can't adopt yet another pet-project which would
> happen if he would use it. That's how he ended up in APT a few months
> after he started using Linux…
>
> All the glory for resumed aptitude development in the recent past (after
> its original author went MIA) needs to go to the new team formed around
> it – especially to Manuel.
>

Well, as it seems you know a bit of the lore :) and probably can do a
bit of myth-busting as well, I had and have seen some old bug-reports
of aptitude in where it is called fat (as in it has in it code which
probably could be shed but isn't either due to not knowing what
functionality that piece of code has or not proper history or
something similar, is also said to be prone to memory leaks and the
only advantage that *some* people think it has. is that it has an GUI
interface (using Tk or some similar low-memory GUI toolkit.) Whereas
something like synaptic takes more memory as it is uses GTK-3.0 or a
more full-featured GUI toolkit.  </strawman argument>

IIRC, there was some talk sometime back where there was talk of
refactoring aptitude (as in rewriting so it's cleaner, probably a bit
shorter and perhaps a bit faster as well.) but that didn't happen as
the code-page has become large and it would make lot of demands on the
team's time without any actual benefit apart from it having benefits
of being cleaner, faster and probably a bit better on the security
side to. Would you or anybody else from the aptitude team care to
comment on it ? Also how much of a myth or reality is the part about
memory leaks and fatness ?

I have used commands like -

$ aptitude search dbgsym | more and then waited and nothing happens
and have had to kill the aptitude instance, dunno if this is a known
bug or not. I have seen these happen more than a few times, whenever I
use a pipe and use more or less with aptitude.

Anyways, more often than not, I use the below three commands for
managing my workstations -

[$] alias aptc
aptc='aptitude search '\''~c'\'

I do understand that sometimes it is desirable to have the
configuration file lying around, while at other times it clearly is a
bug of left-over files but till one is familiar with the package
intimately it is better not to report it.

[$] alias aptn
aptn='aptitude search '\''~N'\'

New packages which have come in due to result of you updating the
index from the last time the index was updated.

[$] alias aptfn
aptfn='sudo aptitude forget-new'

I use this so that noise is reduced quite a bit so whenever I run aptn
I just see new packages and I'm happy with the above commands and the
outputs they generate.

> Best regards
>
> David Kalnischkies
>
> [0] As said in the story, apt and aptitude happily co-exist. The teams
> share even an IRC channel and frequently read/comment/reassign each
> others bugreports. Of course by proxy apt developers have an impact on
> the other frontends like aptitude. At the very least because we maintain
> the underlying shared library and deal with most of the non-user facing
> features in it like the secure download of packages.
>

Look forward to the comments, thank you for giving/sharing an
insightful and interesting answer.

-- 
          Regards,
          Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8


Reply to: