How to use "apt" on PuppyLinux

[s243a]

Part 1. Why I installed apt

After reading the tile of this thread the first question one might ask is why not just use a distro that already has apt installed like debain, ubuntu or debiandog. The reason that I have apt on puppy is not because I actually wanted to install it but instead I was curious about whether or not I could use apt-key to add a pgp key to the keyring for the puppy package manager (see thread).

I actually do not know if the puppy package manager has it's own pgp keyring but from a security perspective it makes sense to trust different people with the authenticating the packages that you install on your system then you do to authenticate a post on some forum or blog.

Part 1.1 - An Example Shortcoming of the Puppy Package Manager

However, even though I installed apt on a whim there are some commands that I'm use to doing on apt that I don't know how to do on puppy. For instance when I tried to install unireedsolomon with pip3, I was told that I was missing a header file. This usually happens when the dev package for python isn't installed. However, I didn't know how to search for the dev package on Puppies Package Manager.

When I tried searing for "python3-dev" nothing showed up. It is easier to search for things on the command line because I can apply multiple filters using grep. For example with apt I found the missing package easily with the command

Code: Select all

 apt-cache search python3 | grep dev

Multiple grep statements can be used if one has multiple search conditions.

2. Okay, but how do I install apt?
2.1 Newer uPups and dPups

If you are running a new uPup of dpup such as dpup Strech, or Xenial, Upup Bionic Beaver, etc...then you can probably install apt directly from the package manager and you'll be most of the way there. However, you'll likely also need to:

1. Install (or re-install) coreutils because the version of mktemp used by busybox doesn't support all of the command line options that are needed by some tools in the apt package (apt-key has this issue).

2. If /var/lib/dpkg/status causes problems (e.g. if it was a directory instead of a file), then delete it. Use the touch command to create it as an empty file and then type:

Code: Select all

apt-get install --reinstall $(</var/lib/dpkg/status sed -n 's/^Package://p')
apt-get update

https://unix.stackexchange.com/question ... pkg-status

One also needs to create the file /etc/apt/sources.list. From strech you can use:

Code: Select all

deb http://deb.debian.org/debian stretch main
deb-src http://deb.debian.org/debian stretch main

deb http://deb.debian.org/debian-security/ stretch/updates main
deb-src http://deb.debian.org/debian-security/ stretch/updates main

deb http://deb.debian.org/debian stretch-updates main
deb-src http://deb.debian.org/debian stretch-updates main

https://wiki.debian.org/SourcesList#Exa ... urces.list

This is where I stopped because all I wanted at this moment was to get was "apt-cache search" to work. However, at a later time I do want to learn how to sync apt with the puppy package manager and visa-versa.

3. Non debian/ubuntu variants and older version of Puppy

There is an article on the puppylinux wiki called Debianization but it is probably too old to be helpful. The keypoint to keep in mind here is that if you start downloading packages from a debian or ubuntu repo then try to pick from a repo where the core c libraries (e.g. glibc) match as close as possible to those of you current system.

This is because trying to update core c libraries will likely cause a novice to break their current system. It's better if they chose packages that don't require one to update their core c libraries. Also one may want to consider compiling the libraries themselves rather than using pre-built binaries either to ensure better comparability or because there is no pre-built binaries for their system.

Anyway, since we are assuming a non debian/ubuntu strain of linux the binaries can be downloaded from web pages if they aren't available on the package manager.

Here are some links for APT:
Debian: jessie Strech
Ubuntu: trusty,xenial, bionic

For older versions the dependency info can still be found on the internet archive:
Debian: lenny, squeez, wheezy
Ubuntu: lucid, Precice


this will let one know what version of the packages to build if they can't find a suitable repo for binaries.

Look Ahead

So far I've only used "apt-cache search" from the apt package. The reason is that I want to try syncing it with the puppy package manager before using apt. If I make progress in the front I will report the details about my progress to this thread.

Also note that there is also an in-house puppy CLI Based package manager, that I would like to try. Perhaps it has the functionality that I would like from APT. Hopefully I'll get to compare in the near future

[nosystemdthanks]

nice. ive tried to do this at least once before, had trouble with it.

you can download .deb packages and "unzip" them using dpkg-deb, which puppy includes. this wont manage a full apt system or track the files after installation-- it is more like using tar or unzip. i use this all the time on non-debian-based distros, and ive even used it with the tahr edition of puppy.

[rockedge]

the in pkg command line package manager works very well for me
does all the apt-get and apt does. At least for me.

http://murga-linux.com/puppy/viewtopic.php?t=112927

it has become quite advanced and worth a look.

[wiak]

I'm a firm believer that the best future for Puppy, when it is in its current form of relying on other distributions for its applications (which is only sensible if access to large repositories wanted), revolves around developments to its (commandline-based/scripting capable) package management system. The aim should be to get Puppy package management 'perfect' - not just able to use, for example, apt-type commands, but to do with with perfect dependency tracking (i.e. as good as debian-system apt). Hopefully that will be the end result of these sorts of work such that as upstream distributions evolve, Puppy will have appropriate and 'perfect' ability to distribution upgrade (like debian systems can). I suppose the argument against it is that debian tends to include a lot of dependencies where cutdown versions of applications could use less (the key possibly also being some kind of 'pinning' solution for specially created Puppy apps such that the package management system tracks them but doesn't try to replace them with debian or similar bloated versions.

wiak

[nosystemdthanks]

ive explored the idea of perfect dependency tracking, and its only possible with greater standards and quality control-- or full automation of package creation.

the only way that will come to puppy is through repos that already have that level of commitment-- and since that is already here, theres not much to do about it.

but people will continue to make their own third party stuff (a reality that distros like debian are only coming to terms with 20 years later-- not their fault really) and that wont change.

if you look away from the distro and at software developers, the mess comes from there. there was never a majority of developers that care if their changes break too many things they dont know about. for example, mozilla deciding that it would require pulseaudio. we are left to fix that with apulse or change our distro. they dont care.

the distro devs are basically cat herders in this regard. you might think im sympathetic to them then. im really not, but this particular problem isnt entirely their fault either.

apt has problems. im not saying there is a system i prefer, im saying the one i think has the fewest problems, has some things i consider fundamentally broken and deeply problematic.

funnily enough, chasing a solution that is fundamentally broken like apt, has its advantages. but it also has costs that puppy users traditionally dont worry about because their typical solution is different.

just to be clear, i too want apt to work in puppy. but far from fixing everything, it will make some things worse if it becomes the new standard (im not terribly worried about that happening.)

the perfect dependency tracking will not happen-- it never has. thats a fallacy, the argument proves nothing, but the conclusion is not false. it simply isnt presented with a real argument.

in other words, just because it never has doesnt prove that it cant. but i think its worth noting as evidence it probably wont happen any time soon.

i only know two major disadvantages of a system like apt:

1. it relies on a bloated local database that seems to go against what puppy is (i dont feel strongly about that, since i mostly use distros that also rely on such a local database. but just the same, it isnt terribly puppy-like by tradition.)

2. sometimes, it forces people to use things they dont want. this isnt very puppy like either, and most (read all) apt-based systems outright refuse to work if you deliberately break dependencies.

someone is going to say "thats like complaining that your refrigerator wont get cold if you remove the power cord."

no, it isnt. its a bit more like saying that even if you dont need eggs, your refrigerator latches the door shut until you go buy eggs, so you cant put milk in it.

heres a solid example: remove your icon packages. nearly all programs will still operate if you remove the icons. i mean they will literally run and function properly.

but apt will complain that there are dependency breakages. this is very unpuppy-like. when people here make packages, sometimes they OPT to remove certain bloat. apt is not particularly helpful to this, in the way that packages are organised. thats why i say it is fundamentally broken in this regard.

when you want something flexible, and you try to bend something inflexible, it typically breaks. thats apt-- often it does ok, but it is not well-suited to this and it never will be. occasionally, that matters.

heres another possible counter-argument:

in a perfect application of the apt system, the icons would be recommends and the applications that "need" them would only count libraries that are required to run as required.

and its true, that the system is made more flexible by such decisions. but there is no way to do that perfectly.

i mean, you can have some users complain that icons arent really needed, and they should be recommends instead of deps-- while others will say that the apps are "broken" without the icons, but they dont want recommends because that brings in WAY too much bloat.

theyre both right. and no matter how you organise packages, apt forces you to choose to cater to one of those groups or the other.

they really cant all be recommends.

meta-packages help here-- you can make a meta-package called "gdmap with icons" and then the user has more control, and everybody is happy.

we can certainly improve on apt, but short of organising better than the entire debian organisation (i hear laughter coming from all corners of the internet) what you really want is to be able to break things in apt dependencies-- with apt being none the wiser.

which goes completely against the perfect tracking concept, incidentally. but its the only way to retain puppys level of flexibility.

truth: apts dependency tracking is only as good as the metadata people give it. the same goes for puppy.

[wiak]

heres a solid example: remove your icon packages. nearly all programs will still operate if you remove the icons. i mean they will literally run and function properly.

but apt will complain that there are dependency breakages. this is very unpuppy-like. when people here make packages, sometimes they OPT to remove certain bloat. apt is not particularly helpful to this, in the way that packages are organised. thats why i say it is fundamentally broken in this regard.

Well, in that case the DebianDogs are seriously broken and apt complains all the time. One of the main points about the DebianDogs is that the base system has always included non-debian versions of some apps because the debian versions are huge because of dependencies. Yet, using apt (dpkg really), doesn't complain... so it not only can be done, it is done. Fred of DD (and Tony, saintless) know far more about this than me, you'd have to check with them for details, but it has certainly proven to be a long term workable system.

Of course, you can break apt/dpkg, but seems to me that such breakage occurs by people installing new apps outside debian apt database knowledge without pinning things in such a way that apt is fine with it all. There may be exceptions to that, but it has always, as far as I recall, turned out to be a user installation error (in terms of not understanding apt/dpkg requirements/configuration methodologies).

dpkg database isn't so terribly huge is it? It's just a simple flat database as far as I know - can't imagine it being particularly large (even when in uncompressed form it is surely not very relevant bloat-wise in these days of 300MB compressed pups?). Of course, keeping copies of files installed in /var/cache/apt/archives, does take up a lot of room, but there is no need to do that.

I have a pretty huge XenialDog system in terms of installed apps (a couple of GBytes compressed filesystem) but my /var/lib/dpkg/status file is only about 1 Mbyte, which, it seems to me, contains all the package/dependency status information. Biggest stuff in /var/lib/dpkg is the info folder, which is simply full of the pre and post install files that were used at install time. That's now about 22Mbyte on my system, but I'd be surprised if I couldn't safely remove that anyway.

Certainly apt itself takes up a lot of room by holding lists of all the packages available in repositories, but I guess you only need that when installing new stuff (and Puppy has to store lists of available stuff for PPM too so no big advantage there).

wiak

[nosystemdthanks]

so it not only can be done, it is done. Fred of DD (and Tony, saintless) know far more about this than me, but it has certainly proven to be a long term workable system.

fair enough. im fond of "proof is in the pudding" arguments, they tend to have merit.

i guess what im saying is, "apt is somewhat broken, at least in debian and ubuntu and some other places." but if its not in dd, then big props to them.

seems to me that such breakage occurs by people installing new apps outside debian apt database knowledge without pinning things

well, i want to point out thats not the situation i referring to at all. i was talking about up-to-date debian-only usage.

user installation error (in terms of not understanding apt/dpkg requirements/configuration methodologies).

mmhmm.

dpkg database isn't so terribly huge is it? It's just a simple flat database as far as I know - can't imagine it being particularly large (even when in uncompressed form it is surely not very relevant bloat-wise in these days of 300MB compressed pups?).

good question. sometime (because its exactly the sort of experiment that i do all the time using distro-libre, a project that ultimately started here on the puppy forum) i will have to create a live version of debian that doesnt have apt, and measure it against the version that does.

i can check that without running an update, and then after.

id like to know as well.

Of course, keeping copies of files installed in /var/cache/apt/archives, does take up a lot of room,

of course. i think (i hope) most people learn that their first year of using a debian-based distro. for me, its been more than 12.

[wiak]

Like I said, its the apt storage of repository lists of packages that takes most room, and Puppy PPM has to store such lists too so no advantage there in practice.

wiak

[dancytron]

According to wikipedia:

Database

The dpkg database is located under /var/lib/dpkg; the "status" file contains the list of installed software on the current system. There is no information about repositories in this database.[12]

On my DD that I use on a daily basis, /var/lib/dpkg/status is 850 KiB, there is also a status-old which is the same size and a statusnew that are roughly the same size.

I bleachbit away all the repository information and reload it when I need it (keeping my changes folder under 20 Mb most of the time). When I bleachbit it away, assuming I haven't installed or upgraded anything, it deletes 72 Mb of package lists and 26.2 Mb each for /var/cache/apt/pkgcache.bin and /var/cache/apt/srcpkgcache.bin.

[nosystemdthanks]

it deletes 72 Mb of package lists and 26.2 Mb each for /var/cache/apt/pkgcache.bin and /var/cache/apt/srcpkgcache.bin.

obviously on an installed system, there is plenty of room if people are willing to tolerate a "full system." such requirements are modest in that context.

i guess a better question is: lets say for the sake of argument, that all versions of puppy switched to apt.

a. how much would that increase the size of the live cd (which i presume many puppy users will continue to use) and

b. how much will it decrease the speed of installing packages?

if the answers to both of these are both truly negligible, then why wasnt apt being used sooner?

(im not pretending i dont know that puppy wasnt always debian-based. it is increasingly debian based these days, though i know slacko also exists.)

[fredx181]

Biggest stuff in /var/lib/dpkg is the info folder, which is simply full of the pre and post install files that were used at install time. That's now about 22Mbyte on my system, but I'd be surprised if I couldn't safely remove that anyway.

The files in /var/lib/dpkg/info cannot be removed, they are there to store exactly what's installed (*.list files) and e.g. a "prerm" script will run when uninstalling a package.

About the subject, I agree with @nosystemdthanks that with package management completely based on apt/dpkg it wouldn't be puppy anymore.
It's one way or the other IMO .
Unless there's some sort of construction for additional (separate) pet package management that won't break dpkg (or the whole system).
(not saying it's impossible, but probably very difficult to do)

i guess a better question is: lets say for the sake of argument, that all versions of puppy switched to apt.

a. how much would that increase the size of the live cd (which i presume many puppy users will continue to use) and

b. how much will it decrease the speed of installing packages?

a. That depends, if you include only applications from the Debian or Ubuntu repos (no self compiled or custom made applications), then probably it will increase very much.

b. No decrease in speed, I think.

Fred

[nosystemdthanks]

I agree with @nosystemdthanks that with package management completely based on apt/dpkg it wouldn't be puppy anymore.
It's one way or the other IMO .

sorry to quibble when youre agreeing with me. ive spent literally years fascinated with "what makes puppy 'puppy'" and puppy continues to have some influence on what i think a gnu/linux distro is.

every time ive tried to get answers about what puppy is, ive gotten a wild array of some good points, some overly specific or overly vague, along with the hard-to-argue-with official point that "puppy is whatever barry says it is" (i dont have a full counterargument to that, not even years later) and by extension, puppy is whatever the people barry has officially bestowed with the responsibility say it is.

my minor counterargument is that puppy is many things, to many people, and there is understandably a great deal of overlap. so i think it would still be puppy, but "probably less so." i am confident it would disappoint some, and im also confident that some would say "its not puppy anymore" but thats not what i was saying-- i was saying it would be less traditionally puppy-like.

while the answer i expect most from such a survey is now "jwm and rox," i dont think that is an adequate assessment of puppy, and indeed when i made a blended distribution (puppy+refracta) the first thing i moved over to refracta+puppy after the wallpaper and rox was petget itself-- not jwm.

Unless there's some sort of construction for additional (separate) pet package management that won't break dpkg (or the whole system).
(not saying it's impossible, but probably very difficult to do)

here im optimistic. im very confident that it would be not only possible, but trivial to create a package (even within the apt system if need be) to add pet package management.

i dont think it would be removed from puppy, but it wouldnt matter. i added petget to refracta. as an application, its not designed in a way that makes it easy to transfer to other environments, though if you want pet package support in just about any distribution that exists-- thats trivial to implement. it wouldnt be a problem, thats not something you have to worry about.

theres another thing to consider-- traditionally, we are warned against mixing packages from other distros as a way to decrease the stability of the installation/setup.

thats a problem that has a surprising amount of time devoted to people solving it, and a lot of progress has come of it. in the next 10 years it might be possible to avoid package management altogether. im not saying it will actually happen, just that it could be possible.

also, .pups are yesterdays news (i created one when .pets were still fairly new) and in 10 years, people may consider the .pet vastly inferior to what barry is doing with easy-os, particularly as a way to get puppy packages to coexist with the apt system, hypothetically.

[fredx181]

sorry to quibble when youre agreeing with me. ive spent literally years fascinated with "what makes puppy 'puppy'" and puppy continues to have some influence on what i think a gnu/linux distro is.

....
....

Yes, well... with agreeing I meant as you wrote "puppy-like", e.g:

2. sometimes, it forces people to use things they dont want. this isnt very puppy like either, and most (read all) apt-based systems outright refuse to work if you deliberately break dependencies.

Not intended to start discussion about "what's a real puppy", most important IMO is what puppy users would like.
I think most puppy users (and developers, not to forget !) wouldn't like it to follow the strict rules of a package management such as apt / dpkg.
But could be , as you say, if it's do-able to have additional petget, without conflicting.


Fred

[bigpup]

You may want to look at this:
Pkg - CLI package manager
http://murga-linux.com/puppy/viewtopic.php?t=112927
If you download and install the pet.
It gives you a GUI to run the program or a command line option to run it.
Can be started from menu>Setup entries.
"GPkgdialog package manager" (GUI)
"Pkgdialog package manager" (CLI)