Hello Craig, On 2/20/19, Craig Sanders via luv-main <[email protected]> wrote: > On Wed, Feb 20, 2019 at 08:11:16PM +1100, Mark Trickett wrote: >> Aha, another piece of using apt-get. It is brilliant, but also a very >> steep >> learning curve. It would be very good to have a good cheat sheet in a >> printable form. > > $ apt-get --help > apt 1.8.0~rc3 (amd64) > Usage: apt-get [options] command > apt-get [options] install|remove pkg1 [pkg2 ...] > apt-get [options] source pkg1 [pkg2 ...] > > apt-get is a command line interface for retrieval of packages > and information about them from authenticated sources and > for installation, upgrade and removal of packages together > with their dependencies. > > Most used commands: > update - Retrieve new lists of packages > upgrade - Perform an upgrade > install - Install new packages (pkg is libc6 not libc6.deb) > reinstall - Reinstall packages (pkg is libc6 not libc6.deb) > remove - Remove packages > purge - Remove packages and config files > autoremove - Remove automatically all unused packages > dist-upgrade - Distribution upgrade, see apt-get(8) > dselect-upgrade - Follow dselect selections > build-dep - Configure build-dependencies for source packages > clean - Erase downloaded archive files > autoclean - Erase old downloaded archive files > check - Verify that there are no broken dependencies > source - Download source archives > download - Download the binary package into the current directory > changelog - Download and display the changelog for the given package
That is a good summary, but what I (and probably others) would find very useful is a more expanded "cheat sheet" with good examples that we can extrapolate from. When I taught myself basic Postscript, I needed a cookbook of examples, the reference manual is good, but to generic in the descriptions of how to do. I still need to comprehend the standard prelude and postscripts portions that are usual. For that, I need more detail than the reference manual, and probably also some intro to Level 3, while what I have is Level 2. > See apt-get(8) for more information about the available commands. > Configuration options and syntax is detailed in apt.conf(5). > Information about how to configure sources can be found in sources.list(5). > Package and version choices can be expressed via apt_preferences(5). > Security details are available in apt-secure(8). > This APT has Super Cow Powers. Again, I am still looking for something a it more verbose, better explaining the detail, rather than just a summary. It is also why I would like a regional interest group relatively local, getting together and learning through group efforts and practice. >> I am now considering two installs on the computer, one stable, the other >> sid, and dual booting to get the scanning. As there is one normal user, I >> should be able to set up a shared home partition and the one user in each >> install sharing the one home directory structure. That way, I still have >> a >> usable system for most things, but can get at the stuff in sid at need. > > That seems overly complicated but it should work. the only thing to be wary > of > is to make sure that your user has the same UID and GID on both systems > (which > should be the default, as debian makes users with UIDs starting from 1000) I really do not want to not have a usable system now I need to use it to send in time cards. I am also (reluctantly) using Internet banking and having to depend on it. I tend to be working hours that preclude using storefront services to pay rates, electricity and Telstra, and more recently, ATO payments. Some I can pay on line with a Mastercard, some I need to use BPay from the bank site. > You probably don't even need a separate /home partition. You could just > mount > the stable system (e.g. as /stable) and symlink /home/mark on the sid system > to /stable/home/mark. Provided that sid does not have a regression or other issue that corrupts the disk, it has happened. For that reason, would have the sid install have a home on that hard drive, and not access the stable or testing. Then use the stable to transfer the files, or else use a USB stick. > Personally, I'd just upgrade to sid. I've never considered the stable > release > to be anything special, its main use to me is providing an installer to > build > new systems with (that then get immediately upgraded to sid). > > I'm biased, though: I've been using debian unstable since the 90s. BTW, the > only reason why "unstable" is called "unstable" is because a CD distributor > in 1994 or 1995 jumped the gun and released a "Debian 1.0" CD before it was > ready. The name was deliberately chosen to be scary enough to discourage > anyone from doing the same thing again...it doesn't mean that it's flaky or > crash-prone. My first copy of Linux was floppys that I never had the space to try, then Yggdrasil on CD with the drivers for a proprietary interface, then Red Hat (5.2?) which installed and configured X and introduced me to dependency hell, which is why I looked to Debian, but never developed the skill to cope in the early stages. Dselect and glacial responses during the install leading to mistakes and such, not really enough processor or RAM. Then Ubuntu for a while and now Debian with a vastly improved installer. > IMO, obsessing over the "stable" release of debian misses one of the best > and > most important features of debian - it's a constantly updating distribution > with new and updated stuff every day. This occasionally (rarely) causes > problems but a) as long as you're careful and don't let apt uninstall stuff > you don't want it to, it's no big deal and b) those problems are almost > always > easily fixed....back in the 90s there were occasionally some huge problems, > but not since the transition from libc5 to libc6 in 1998 (which required a > very precise and complicated upgrade procedure. I wrote a script called > autoup.sh to completely automate the procedure, taking into account the > vagaries and bugs reported by many people at the time. This was before apt > existed, which automates the kind of dependency resolution I had to do in my > script: my script was a one-off hard-coded hack, while apt analyses the deps > etc and arrives at a solution) I seem to remember dselect and dpkg and the like handling dependencies early, not necessarily as well as they do today, but that was a big reason why I prefer Debian and Debian based distributions. Just I would like it if Debian would better support alternatives to systemd, or at least better componentize systemd for selection of which bits each of us wish to use. > The biggest problem with sid these days is the constant churn of KDE and Qt > packages (and, to a lesser extent, gnome). I've found that the best way to > avoid problems there is to use 'apt-mark' to hold the few KDE & Qt apps I > use > (okular, qdfview, calibre) so that they don't get auto-uninstalled due to > versioned dependencies (doing that causes the KDE and/or Qt packages to not > get upgraded if that would cause the help packages to be removed). Some of that is up to the developers and Debian porting people to not rush the new "features" and minor updates. If you really think your latest "improvement" is so damn good, then also do a backport that does not break things for those running the prior version, do not force them to do all the upgades that will break a working system. Yes, that software is their "baby", but it is only a component of the whole system. > craig Regards, Mark Trickett _______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
