USM Unified Slackware Package Manager

Here is a place for your projects which are not officially supported by the Porteus Team. For example: your own kernel patched with extra features; desktops not included in the standard ISO like Gnome; base modules that are different than the standard ISO, etc...
User avatar
francois
Contributor
Contributor
Posts: 4990
Joined: 28 Dec 2010, 14:25
Distribution: kde xfce porteus manjaro kubun
Location: Enfin l'été, le changement climatique attendu: le soleil.

Re: USM Unified Slackware Package Manager

Post#316 by francois » 09 Sep 2014, 16:57

I have the impression that you just nailed it down:
EDIT: In the screenshot he/she clearly has the USM window open. At the bottom you can clearly see: STORAGE: /tmp/usm.
Reading the article, I had the impression that he had used usm. And clearly he did.

During the download process there is an option to convert to modules
He did or maybe did not saw that option, though it is there. In one hand, he did not know the consequences of not activating them. On the other hand, he cannot assume that all distributions are gentoo like or debian like. Maybe he should have read a little more. He did not took the time to see what was wrong.

To be kept as a small and lightning fast distro porteus still sticks to the use of the /porteus/optional folder. We understand that because we come from slax. And we know by experience that the crowding of /porteus/modules folder will slow down the booting process. We are also aware of the dependencies issues.

Conclusions, first there should be a probe about activating the modules otherwise, it will not be operant, as usually people expect that the package manager will result in installing a functional package. Second, there should be a warning about the special modular nature of modules and refer to the choice the user has to place modules in the most appropriate location (wiki or howto)

My few thoughts on the issue.
Voltaire: Le mieux est l'ennemi du bien.

beny
Full of knowledge
Full of knowledge
Posts: 729
Joined: 02 Jan 2011, 11:33
Location: italy

Re: USM Unified Slackware Package Manager

Post#317 by beny » 09 Sep 2014, 17:27

brokenman you have done a good job the salix repository is available thank to you for the first time out of salix environment,deps search is ok i have just try with vlc from salix repos and all the txz are stored into /tmp/usm so via cli it is possible to merge all the packages into one xzm package,i don't have a gui,i think if someone know porteus don't search other system.

User avatar
brokenman
Site Admin
Site Admin
Posts: 5504
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: USM Unified Slackware Package Manager

Post#318 by brokenman » 09 Sep 2014, 23:18

there should be a probe about activating the modules
Ok so if I understand correctly, the popup window asking if the user wants to 'open' the storage folder should instead be ... "Would you like to activate/install the downloaded packages?"
How do i become super user?
Wear your underpants on the outside and put on a cape.

sean
Contributor
Contributor
Posts: 144
Joined: 08 Jul 2012, 02:30
Distribution: Porteus v3.0 LXDE i486
Location: South Central PA, USA

Re: USM Unified Slackware Package Manager

Post#319 by sean » 10 Sep 2014, 00:03

@brokenman,

You know the fella that did the review perhaps was in a hurry or something. francois has made a good point about an activation probe. Most distro's do an automatic install after a download, but we don't.

I would suggest giving a day or so of thought to how you wish to word any instructions. Because of our unique download/install/activate method, it might be a good idea to address the "optional" directory in /porteus also. I'm thinking here of something along the lines of:

You have, or are about to, download(ed) a package from a respoitory. You have 2 options:
1 - Install the package/module after downloading (Porteus calls this "Activate")
2 - Save the package/module in a holding directory on the system which you can access and Install/Activate at a later time. That holding directory is /porteus/optional.

Also the common "layperson -1/4 geek" (me) should be reminded of the effect a sizeable package/module may have on the system.

This then brings up another quandry, how does the user learn/remember/know how to move a package from "optional" to "modules" and Activate it? We know, but is there some easy way to learn them how to do it :-)

Just thinkin,

Sean

User avatar
francois
Contributor
Contributor
Posts: 4990
Joined: 28 Dec 2010, 14:25
Distribution: kde xfce porteus manjaro kubun
Location: Enfin l'été, le changement climatique attendu: le soleil.

Re: USM Unified Slackware Package Manager

Post#320 by francois » 10 Sep 2014, 00:58

Sean:
You know the fella that did the review perhaps was in a hurry or something

This is clear. Maybe he should have read wikipedia on porteus or our first faq about What is porteus? But sadly even if he had done that it seems that the first is outdated and the second does not put in evidence on of the most genuine characteristic of porteus: the modules.

Most of his discussion is positive. He has some difficulties with usm but does not have the time to understand what is going on. Then surprisingly he concludes that the porteus distribution is somewhat weak:
http://distrowatch.com/weekly.php?issue ... 08#feature
Were I to evaluate Porteus as a general purpose operating system the distribution would fail to gain good marks in most areas. Porteus does not play well with USB thumb drives, the installer really doesn't give us much flexibility, we are given one default user account, no practical security and no meaningful way to acquire additional software.

I use porteus as my main distribution. The only limit of porteus is that it is based on slackware (less software pasture), but the good news is that it has also its stenghts: its efficient and solid.
Voltaire: Le mieux est l'ennemi du bien.

User avatar
brokenman
Site Admin
Site Admin
Posts: 5504
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: USM Unified Slackware Package Manager

Post#321 by brokenman » 16 Sep 2014, 00:03

How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
francois
Contributor
Contributor
Posts: 4990
Joined: 28 Dec 2010, 14:25
Distribution: kde xfce porteus manjaro kubun
Location: Enfin l'été, le changement climatique attendu: le soleil.

Re: USM Unified Slackware Package Manager

Post#322 by francois » 16 Sep 2014, 00:50

brokenman wrote:
there should be a probe about activating the modules
Ok so if I understand correctly, the popup window asking if the user wants to 'open' the storage folder should instead be ... "Would you like to activate/install the downloaded packages?"
I have the impression that this would exactly do the job.

How about the other observers?
Voltaire: Le mieux est l'ennemi du bien.

Bogomips
Full of knowledge
Full of knowledge
Posts: 2560
Joined: 25 Jun 2014, 15:21
Distribution: 3.2.2 Cinnamon & KDE5
Location: London

Re: USM Unified Slackware Package Manager

Post#323 by Bogomips » 22 Sep 2014, 15:12

  1. Code: Select all

    root@porteus:/home/guest# usm -v
     You are using USM version:  3.1.6
    root@porteus:/home/guest# usm -i libxt
    
     The following items were found.
     Choose an number to confirm. 
     ctrl+c to quit
    
    1) libXt-1.1.4-i486-1.txz
    2) libXtst-1.2.2-i486-1.txz
    #? 2
    
    Found "Choose an number to confirm." somewhat confusing. Looked like it was going to enter a download phase. Less confusing would have been "Choose an number to view.", for example.
    • Code: Select all

      root@porteus:/home/guest# usm -s libcl
      
      Nothing was found in Slackware but i found this in slackbuilds.
      
      NAME :  libcli 
      CATEG: libraries
      DESC : libcli (cisco style telnet commandline interface library)
      VERS : 1.9.4
      
       Would you like to attempt to build this from source? [y/n]
      Source of Confusion?

      Code: Select all

      OpenCL library and ICD loader from NVIDIA.
      
      Packager: Felix Yan <felixonmars@gmail.com>. License: custom
      
      Binary package:
      
      libcl-1.1-4-i686.pkg.tar.xz
      
      libcl-1.1-4-i686.pkg.tar.xz was sought for package. Suppose it's a difficult decision to decide whether to present libcl?, but in this case one could very well have gone ahead and built the wrong package.
    Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
    NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB

    User avatar
    Ed_P
    Contributor
    Contributor
    Posts: 3214
    Joined: 06 Feb 2013, 22:12
    Distribution: Cinnamon 3.2.2 64-bit ISO
    Location: Western NY, USA

    Re: USM Unified Slackware Package Manager

    Post#324 by Ed_P » 27 Sep 2014, 14:16

    A USM suggestion.

    I recently used the USM Gui to create a module for kpat and when done I clicked on the button to have it open the /tmp/usm/ directory. The /tmp/usm/ window opened and was filled with about 2 dozen files, the dependencies that downloaded, and the single module file in the middle. It took me a moment to see the .xzm file. A newer newbie than I may think that the module wasn't created or that they needed all the dependencies in addition to the actual module.

    It might be wise to delete the dependency files after the module is created. Or create a separate directory for the module, /tmp/usm/xzm for example. Thus when a module is created and the Open Folder option is selected there is no confusion as to what file has been created and needs to be moved to the porteus/extramods directory.
    Ed

    User avatar
    brokenman
    Site Admin
    Site Admin
    Posts: 5504
    Joined: 27 Dec 2010, 03:50
    Distribution: Porteus v3.2rcX all desktops
    Location: Brazil
    Contact:

    Re: USM Unified Slackware Package Manager

    Post#325 by brokenman » 02 Oct 2014, 02:27

    I have the impression that this would exactly do the job.
    @Francois
    Added option in GUI to install packages instead of opening target folder.
    Found "Choose an number to confirm." somewhat confusing. Looked like it was going to enter a download phase.
    @ Bogomips
    Sorry, I disagree. If you are requesting info (-i) why would one think it is entering a download phase? The label here is a generic CLI menu so it is the same label for whatever calls it. Changing it for one (-i) could make it confusing for another (-g) so I will stick with the generic label for now.
    It might be wise to delete the dependency files after the module is created.
    @Ed_P
    This is not viable in the case where one wants to manage packages. Deleting the slackware package means it will need to be redownloaded next time it is required as a dependency. I think leaving deletion of files to the user is the best idea.

    Thanks for the suggestions.
    How do i become super user?
    Wear your underpants on the outside and put on a cape.

    User avatar
    Ed_P
    Contributor
    Contributor
    Posts: 3214
    Joined: 06 Feb 2013, 22:12
    Distribution: Cinnamon 3.2.2 64-bit ISO
    Location: Western NY, USA

    Re: USM Unified Slackware Package Manager

    Post#326 by Ed_P » 02 Oct 2014, 04:03

    brokenman wrote:
    It might be wise to delete the dependency files after the module is created.
    @Ed_P
    This is not viable in the case where one wants to manage packages. Deleting the slackware package means it will need to be redownloaded next time it is required as a dependency.
    I don't understand. If a package is added to a module why would it need to be added to a different module? If it's active in one isn't it available to other modules? And once the module is created when the system is rebooted these /tmp/usm packages are all deleted.
    Ed

    User avatar
    brokenman
    Site Admin
    Site Admin
    Posts: 5504
    Joined: 27 Dec 2010, 03:50
    Distribution: Porteus v3.2rcX all desktops
    Location: Brazil
    Contact:

    Re: USM Unified Slackware Package Manager

    Post#327 by brokenman » 02 Oct 2014, 10:13

    If a package is added to a module why would it need to be added to a different module?
    Yes, but this assumes one is moving the package to the modules folder and actually WANTS them activated at every boot. Some people may prefer to activate on demand and in this case may even prefer bundles.
    And once the module is created when the system is rebooted these /tmp/usm packages are all deleted.
    Assuming one does not use changes.
    How do i become super user?
    Wear your underpants on the outside and put on a cape.

    User avatar
    Ed_P
    Contributor
    Contributor
    Posts: 3214
    Joined: 06 Feb 2013, 22:12
    Distribution: Cinnamon 3.2.2 64-bit ISO
    Location: Western NY, USA

    Re: USM Unified Slackware Package Manager

    Post#328 by Ed_P » 02 Oct 2014, 14:11

    brokenman wrote:
    And once the module is created when the system is rebooted these /tmp/usm packages are all deleted.
    Assuming one does not use changes.
    changes=EXIT does not save the /tmp/ directory.
    Ed

    User avatar
    fanthom
    Site Admin
    Site Admin
    Posts: 4592
    Joined: 28 Dec 2010, 02:42
    Distribution: Porteus Kiosk
    Location: Poland, currently - Cork, IE
    Contact:

    Re: USM Unified Slackware Package Manager

    Post#329 by fanthom » 02 Oct 2014, 14:32

    /tmp folder should be used for storing of temporary files.
    if USM files supposed to be persistent then i would consider placing them in /usr/share/usm or even /opt/usm.
    Please add [Solved] to your thread title if the solution was found.

    User avatar
    Ed_P
    Contributor
    Contributor
    Posts: 3214
    Joined: 06 Feb 2013, 22:12
    Distribution: Cinnamon 3.2.2 64-bit ISO
    Location: Western NY, USA

    Re: USM Unified Slackware Package Manager

    Post#330 by Ed_P » 02 Oct 2014, 15:46

    Ideally, if a user selects the USM option to have the downloaded packages made into a module the module could be placed in the user's extramod directory, either by default or as an option. That would eliminate the user having to find it amongst all the dependencies.
    Ed

    Post Reply