I wrote a script that does a full dist-upgrade.
This is useful when 1) I must do a distribution upgrade 2) I want trasform a non-full to a full installation The idea is that 1) the install-new command just install packages added from latest stable 2) many files are presents in more than one package and in more than one repository 3) when I have two packages with different name in two different repositories, the upgrade of a package override the other that may be unwanted; for example when you install ktown5 you should uninstall kscreen becouse ktown5 has kscreen2; if you do not that, when slackware upgrade kde4 kscreen override kscreen2 even if it is in PKGS_PRIORITY. This script avoid it. The script does 1) slackpkg install-new 2) slackpkg install all missing packages in PKGS_PRIORITY and patches and slackware repositories 3) slackpkg upgrade-all 4) slackpkg remove packages not in PKGS_PRIORITY or patches or slackware (so it remove extra and other REPOPLUS repository not in PKGS_PRIORITY) 5) check if packages installed at step 3 did some override some not opportune override 6) slackpkg clean-system 7) slackpkg new-config I can add optionally the check of conflicts package installed previously; this take many time to run since has to test all packages, but it's the only way to repair a previous bad upgrade (tipically a large slackpkg upgrade as kde upgrade when there is ktown installed). dist-upgrade.sh : Code:
#!/bin/bash |
Quote:
Actually I am even more comfortable doing a fresh installation, then installing the new versions of the third party packages and checking that they work, copying my data, eventually moving only when everything works as expected in the new system. IMHO too much automation hurts. I am afraid that if users less knowledgeable than you use it, you will receive more support requests than you can handle. |
feature to show the url of package and full filelist in slackpkg info.
What do you think? Code:
# DETAILED_INFO=yes slackpkg info slackpkg+ Code:
# DETAILED_INFO=filelist slackpkg info slackpkg+ Code:
diff --git a/src/slackpkgplus.sh b/src/slackpkgplus.sh |
I do not see the need for one more front-end when for instance the file list can already be displayed several ways: pkgtool => view or "most /var/log/packages/<package name>".
“Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher.” (Antoine de Saint-Exupéry). |
Yes, I agree, but the var/log/packages contains just the installed packages.
For all other I must download it then tar tvf it or grep in /var/lib/slackpkg Who use slackpkg & slackpkg+ WANT a frontend. There are other frontend for that? |
regards the issue for dir:// repositories, I fixed it and substituted ls with find.
When I wrote it, I did not use find becouse I can't know the structure of the tree, and if it contains many subdir it can slow down the start of slackpkg in any command (search,upgrade,update,...). In effect, dir:// may be a dedicated directory containing just packages, but may be a directory containing any other things. So I tried to put dir://home/ as local repository (about 200.000 mixed files) It take about 10 seconds before start commands. I think that it is an acceptable time (how many people set the entire home as local repository? He does it at his own risk). please try it before I commit (apply to 1.7.b3): Code:
--- a/src/slackpkgplus.sh |
I'm reorganizing the slackpkg+ official repositories.
I want continue to support the -1.6 version for a lot. So I'm thinking that structure (that I will insert in repositories.txt in next commit) http://slakfinder.org/slackpkg+/ --> latest slackpkg+ stable version http://slakfinder.org/slackpkg+1.6/ --> the 1.6.x version; it will be supported for a lot http://slakfinder.org/slackpkg+1.7/ --> the 1.7.x version; the next stable version http://slakfinder.org/slackpkg+current/ --> the current version; use it to try new features http://slakfinder.org/slackpkg+dev/ --> the development version; use it to help the development currently slackpkg+1.6/ is a link to slackpkg+/ slackpkg+1.7/ and slackpkg+current/ is a link to slackpkg+dev/ When slackpkg+ 1.7 stable will be released, slackpkg+/ will be a link to slackpkg+1.7/, so all users automatically upgrade to it. Who want continue to use slackpkg+ 1.6 have to point to slackpkg+1.6/ directly. slackpkg+current/ will be a snapshot of slackpkg+dev/ tree slackpkg+1.6/ will be mantained for fixes slackpkg+1.7/ will be mantained for fixes and minor updates what do you think of that plan? Currently repositories.txt contains some 14.2 repository from microlinux. Someone are preparing some 14.2 repository? |
Quote:
Why not try to follow an approach similar to Slackware: One stable version + one development version? You could have slackpkg+/ link to the latest stable version (1.6 today and 1.7 when it's released). So I would see: slackpkg+dev/ will be the development tree (I would not name it "current" to avoid a possible confusion that it's a package for Slackware -current. It's not) slackpkg+/ will be a link to the latest stable version (slackpkg+1.6/ for now) slackpkg+1.7/ will be created when a new stable version is released based on dev tree. slackpkg+/ will then be changed to link to this latest stable version. |
In git, usually, the master branch is a development code, for stable versions you may use git tags and any non-master branches, and for testing new features you can use another branch(es). That will just simplify your work. Yes, I know, you prefer to do all the actions manually, but why you don't use git, I don't understand. IMO git is not so difficult to learn...
|
Quote:
The -current even if it is not a -stable tree, however should have less experiments. The reason for a public -dev is just becouse I want keep public all experiments. Quote:
Quote:
Quote:
Quote:
however for git I'm trying to reorganizing the ideas, and one it to put -current as master and -dev in another branch. Many time I used git reset and git push forced in a branch; the -master branch is not a good candidate for that operation. Quote:
Quote:
Also git give best results when a project has many indipendent files. Here I've a single big file that is not simple to manage (I already tried to cut in in multiple files, but it did not add many value). Here git is just used to 1) keep track of modifies 2) keep it public in a simplest way 3) allow me to work from many computers To discuss patches and bug the best way is linuxquestions (the real best place should be slacky.eu in italian language ;), but I cannot ask the moon :) ). |
4 Attachment(s)
Hello,
I have some new code (beta) that should be, I guess, useful. This is currently for slackpkg+/devel (ie. 1.7.b3), but could be backported to previous version(s), and even, to slackpkg. This is a simple extension to the dialog shown in response to commands install, upgrade, and upgrade-all, which allows users to check the changelog for the selected packages. To do that, I added a button, called ChangeLog, between the Ok and Cancel buttons of the packages selection dialog. For instance, running slackpkg upgrade patches will show this : Attachment 21108 When the button ChangeLog is clicked, a textbox is displayed with the changelog entries for the selected packages, like as below : Attachment 21109 When the changelog textbox is closed, the packages selection dialog is restored, with the exact same selection as before. For instance: Attachment 21110 The code is in beta stage and must be tested and reviewed by anyone interrested. Attachment 21111 Code:
--- slackpkgplus.sh.git.1.7.b3 2016-03-10 11:09:31.987399437 +0100 -- Seb |
Zerouno, do you want slackpkg+ "stable: questions/troubles here or in a separate thread?
|
Quote:
|
Quote:
|
Quote:
Version 1.7.b4 - 14/Mar/2016 - slackpkg search now search in dir:// repositories too. - subdirectory allowed in dir:// repositories. - slackpkg search honour correctly the '+' character - Added 'ChangeLog' dialog box to show the changelog of selected packages (thanks to phenixia2003) the dialog function(s) contain a bug regard the size of it. For the changelog, the dialog is 19x70, but the slackware changelog contains rows up to 79 columns. For package list, 'package name'+'repository name' may be longer than 70 characters. This is not a large problem since few packages have long name, and the changelog dialogbox is a non-critical feature, but I think it's the time to solve it. |
All times are GMT -5. The time now is 05:22 PM. |