Best way to remove packages from being offered to install by packageinstaller?

Forum Forums antiX-development antiX Respins Best way to remove packages from being offered to install by packageinstaller?

  • This topic has 15 replies, 3 voices, and was last updated Dec 14-3:19 pm by andyprough.
Viewing 15 posts - 1 through 15 (of 16 total)
  • Author
    Posts
  • #47158
    Member
    andyprough

    I’m working on a little respin for a few friends who are free software advocates to show them that antiX can be made as free from proprietary software as Trisquel, Parabola, and other FSF endorsed distros. Removing the non-free and contrib repos and firmware packages from antiX is obviously easy, but I have a question about packageinstaller. To be FSF level of free, a distro can’t have anything that even offers to install specific proprietary packages for you. So I’m wondering the best way to remove Adobe Reader, Freeoffice, Teamviewer, and a few of the other proprietary offerings from packageinstaller? My preliminary work shows that I can remove them simply by removing the various “.pm” files from /usr/share/packageinstaller-pkglist/ – that works well. I’m also thinking I could remove the .pm files from the packageinstaller-pkglist source package and rebuild it. But before I do that I wanted to throw the question out here on the forum and ask if there is a best practice for changing the offerings in packageinstaller?

    #47159
    Member
    skidoo
    Helpful
    Up
    0
    :D

    sysadmin curating/tailoring the selection of available items within packageinstaller?
    I have never seen it discussed in the forum.

    There’s nothing grep’pable within the *.pm files to determine which are non-free,
    so a sysadmin would need to develop and manually maintain a blacklist (axe list?)

    Even if you (or a daily?hourly? cronjob) were to nix the undesirable *.pm files,
    each time the “packageinstaller” package is upgraded (during ‘sudo apt upgrade’)
    any manually edited *.pm files are at risk of being overwritten and any “missing” files replaced with fresh copies.

    The dpkg suite provides a utility named ‘dpkg-divert’ which a sysadmin can used to protect (one-by-one) select files.
    (see: man dpkg-divert)

    sudo dpkg-divert -add –local /usr/share/packageinstaller-pkglist/somefile.pm -divert /some/other/path

    Your “/some/other/path” could be a holding pen subdirectory, or you might specify (I’ve never tried doing so) “/dev/null” as the divert-to destination

    Instead of using a (daily?hourly?) cron task, I would suggest
    sudo mkdir -p /usr/share/packageinstaller-pkglist/mydiverted
    and specify that directory as the ‘dpkg-divert’ divert-to destination for the unwanted *.pm files
    -=-
    Additionally, for the sake of testing (and for ongoing monitoring, across apt update operations)
    placing a line in the desktop session startup file to launch a “mywatcher.sh” script

    Install the (tiny) ‘inotify-tools’ package if it is not preinstalled on your system and review the inotifywatch manpage and inotifywait manpage.

    
    #!/bin/bash
    ###     mywatcher.sh
    inotifywait -mr -e create -e modify /usr/share/packageinstaller-pkglist/mydiverted
    yad --text “$(echo “$(date)”)\n\n new activity in\n\npackageinstaller-pkglist/diverted directory\n” --button=”OK”& disown
    sleep 60 ### debounce (avoid multiple popups triggered by a single apt update operation)
    • This reply was modified 6 months, 1 week ago by skidoo. Reason: added 'code' tags to preserve double-dash strings
    #47160
    Member
    skidoo
    Helpful
    Up
    0
    :D

    aw, what’s the necessary but omitted final line of the mywatcher script?
    Something along the lines of this, to rearm the watcher:

    pidof -x mywatcher && killall mywatcher; sleep 1; nohup /path/to/mywatcher.sh > /dev/null 2>&1 &

    re: the -m option for inotifywait
    could omit that if you will be “rearming” the script but, IIRC, no harm
    (no multiple watch processes/instances, no additional resources consumed)
    from repeatedly issuing watches on an identical, already-being-watched, path

    #47161
    Member
    andyprough
    Helpful
    Up
    0
    :D

    These are really great ideas, thank you. I was unaware of dpkg-divert – very interesting tool, I think you are right in how it could be used. I’m thinking I could possibly set up a small repo with a few packages, and one of them could be a “packageinstaller-pkglist-blacklist” that would be a small script using dpkg-divert. Then I could just follow the progress of packageinstaller-pkglist on the antiX github page to know when to update my blacklist package.

    #47163
    Member
    skidoo
    Helpful
    Up
    0
    :D

    > set up a small repo with [..] packageinstaller-pkglist-blacklist

    Examining the code within Xecure’s utility would probably be helpful toward your goal
    https://gitlab.com/nXecure/my-offline-repo

    > follow the progress of packageinstaller-pkglist on the antiX github page to know when

    github
    ^—v
    https://gitlab.com/users/antiX-Linux/projects
    https://gitlab.com/antiX-Linux/packageinstaller

    ( mentioning for the benefit of anyone reading this )
    At the gitlab site, if logged in and you “watch” a project repository (e.g. the packageinstaller project repo)
    you can, optionally, receive an email each time a new commit event occurs. Similarly, if participating in
    a gitlab project “issue” discussion topic, you can opt to receive notification of new posts.

    #47230
    Forum Admin
    anticapitalista
    Helpful
    Up
    0
    :D

    Another idea. antiX packages 2 package list debs.

    1. libre
    2. extra non-libre

    antiX will ship with 1 and 2. Your FSF spin will ship with 1.

    All we need is a list of non-libre .pm files.

    Philosophers have interpreted the world in many ways; the point is to change it.

    antiX with runit - leaner and meaner.

    #47262
    Member
    andyprough
    Helpful
    Up
    0
    :D

    Another idea. antiX packages 2 package list debs.

    1. libre
    2. extra non-libre

    antiX will ship with 1 and 2. Your FSF spin will ship with 1.

    All we need is a list of non-libre .pm files.

    If you could do that, that would be really great! I have a list of packages that I need to study their licenses, as I’m not so familiar with them. I’ll do the research and then post a list here sometime over the next week hopefully. I really appreciate the offer, very much hope we could do this.

    #47270
    Member
    andyprough
    Helpful
    Up
    0
    :D

    OK, after some research I believe that the attached list is the group that would be best to be in the extra-non-libre package. Some of them are arguable – for example, Virtualbox is open source, but it has a vital closed source add-on component that is necessary for running USB 2.0 and 3.0 devices. Some others, like some of the vpn packages, have some open source components and some proprietary components, and I wasn’t able to always tell which was which and how they are combined together. chromium is publicly perceived to be the free version of Chrome, but does still have some non-free components embedded in it.

    It’s not a long list. Let me know if you do decide to split packageinstaller-pkglist up into the two packages, it would be incredibly helpful.

    • This reply was modified 6 months, 1 week ago by andyprough.
    #47299
    Forum Admin
    anticapitalista
    Helpful
    Up
    0
    :D

    chromium is in Debian main unlike virtualbox (in contrib).
    So it is free since Debian follows the FSF for all debs in main. I think.

    Also these should also stay IMO:

    HP_printing.pm
    java.pm

    What about
    waterfox_classic.pm
    waterfox_current.pm

    Philosophers have interpreted the world in many ways; the point is to change it.

    antiX with runit - leaner and meaner.

    #47302
    Member
    andyprough
    Helpful
    Up
    0
    :D

    chromium is in Debian main unlike virtualbox (in contrib).
    So it is free since Debian follows the FSF for all debs in main. I think.

    Also these should also stay IMO:

    HP_printing.pm
    java.pm

    What about
    waterfox_classic.pm
    waterfox_current.pm

    You are right, both Debian and the FSF-approved PureOS include chromium. If that’s the case, then I would prefer that brave.pm be included on the libre list, since Brave apparently doesn’t add any proprietary code to chromium, and Trinity College in Dublin earlier this year found that Brave was the one browser that did not phone home user data.[1]

    On HP_printing.pm – looks like you are right, Debian main does include hplip, which from my review included “mixed” gpl and commercial code. So that one’s OK if the libre list is following Debian.

    On java.pm – Debian includes all the different versions of openjdk. As long as java.pm is a pointer for installing openjdk packages, that should be fine on the libre list.

    On waterfox_classic.pm and waterfox_current.pm (and waterfox_g3.pm by extension) – Debian does not include them, but I can’t find anything showing that they are proprietary. Everything I read indicates they are under the same Mozilla public license as Firefox. I think the reason Debian excludes Waterfox is probably the same trademarks of artwork and brand name that kept Debian from including Firefox for several years until recently. Debian appears to exclude Waterfox, Palemoon and Brave on this same basis – free software that trademarks its artwork and brand name. I don’t personally agree with Debian on this point, and I think all the Waterfox, Brave, and Palemoon .pm files should be included on the libre list, especially since the Palemoon variants are so vital to running on much older cpu’s.

    Based on the above, I’ve attached an updated list.

    [1] https://www.scss.tcd.ie/Doug.Leith/pubs/browser_privacy.pdf

    • This reply was modified 6 months, 1 week ago by andyprough.
    #47309
    Forum Admin
    anticapitalista
    Helpful
    Up
    0
    :D

    debs should appear in repos soon.

    You’ll see a new Package Installer deb which enables both the old pkglist and new ones to co-exist.

    One you have updated package Installer, you can then install packageinstaller-pkglist-libre.
    This will remove the old packageinstaller-pkglist.

    Philosophers have interpreted the world in many ways; the point is to change it.

    antiX with runit - leaner and meaner.

    #47317
    Member
    andyprough
    Helpful
    Up
    0
    :D

    debs should appear in repos soon.

    You’ll see a new Package Installer deb which enables both the old pkglist and new ones to co-exist.

    One you have updated package Installer, you can then install packageinstaller-pkglist-libre.
    This will remove the old packageinstaller-pkglist.

    Awesome! I’ll try it this afternoon.

    #47323
    Forum Admin
    anticapitalista
    Helpful
    Up
    0
    :D

    They are there now (repo.antixlinux.com).

    
    The following packages will be upgraded:
       app-select-antix (0.1.6 => 1.0.1)
       packageinstaller (0.2.5 => 0.2.6)
    2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
    Need to get 113 kB of archives.
    After this operation, 6,144 B of additional disk space will be used.
    Do you want to continue? [Y/n] 
    Get:1 http://repo.antixlinux.com/buster buster/main amd64 app-select-antix all 1.0.1 [7,068 B]
    Get:2 http://repo.antixlinux.com/buster buster/main amd64 packageinstaller amd64 0.2.6 [106 kB]
    Fetched 113 kB in 3s (42.9 kB/s)           
    (Reading database ... 301881 files and directories currently installed.)
    Preparing to unpack .../app-select-antix_1.0.1_all.deb ...
    Unpacking app-select-antix (1.0.1) over (0.1.6) ...
    Preparing to unpack .../packageinstaller_0.2.6_amd64.deb ...
    Unpacking packageinstaller (0.2.6) over (0.2.5) ...
    Setting up packageinstaller (0.2.6) ...
    Setting up app-select-antix (1.0.1) ...
    Processing triggers for mime-support (3.62) ...
    Processing triggers for desktop-file-utils (0.23-4) ...
    Writing Menu: jwm
    Writing Menu: fluxbox
    Writing Menu: icewm
    root@L412:/home/anticap# apt install packageinstaller-pkglist-libre 
    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    The following packages will be REMOVED:
      packageinstaller-pkglist
    The following NEW packages will be installed:
      packageinstaller-pkglist-libre
    0 upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
    Need to get 61.8 kB of archives.
    After this operation, 49.2 kB disk space will be freed.
    Do you want to continue? [Y/n] 
    Get:1 http://repo.antixlinux.com/buster buster/main amd64 packageinstaller-pkglist-libre all 0.1.0 [61.8 kB]
    Fetched 61.8 kB in 1s (53.2 kB/s)                         
    dpkg: packageinstaller-pkglist: dependency problems, but removing anyway as you requested:
     packageinstaller depends on packageinstaller-pkglist | packageinstaller-pkglist-libre; however:
      Package packageinstaller-pkglist is to be removed.
      Package packageinstaller-pkglist-libre is not installed.
    
    (Reading database ... 301887 files and directories currently installed.)
    Removing packageinstaller-pkglist (0.3.27) ...
    Selecting previously unselected package packageinstaller-pkglist-libre.
    (Reading database ... 301044 files and directories currently installed.)
    Preparing to unpack .../packageinstaller-pkglist-libre_0.1.0_all.deb ...
    Unpacking packageinstaller-pkglist-libre (0.1.0) ...
    Setting up packageinstaller-pkglist-libre (0.1.0) ...
    r-pkglist | packageinstaller-pkglist-libre; however:
      Package packageinstaller-pkglist is to be removed.
      Package packageinstaller-pkglist-libre is not installed.
    
    (Reading database ... 301887 files and directories currently installed.)
    Removing packageinstaller-pkglist (0.3.27) ...
    Selecting previously unselected package packageinstaller-pkglist-libre.
    (Reading database ... 301044 files and directories currently installed.)
    Preparing to unpack .../packageinstaller-pkglist-libre_0.1.0_all.deb ...
    Unpacking packageinstaller-pkglist-libre (0.1.0) ...
    Setting up packageinstaller-pkglist-libre (0.1.0) ...

    Philosophers have interpreted the world in many ways; the point is to change it.

    antiX with runit - leaner and meaner.

    #47385
    Member
    andyprough
    Helpful
    Up
    0
    :D

    Wow, it worked!! This is really great, thank you very much anticapitalista. And the respin is working well so far on my Dell without using any firmware. I’m using the 4.19 kernel version to give myself an advantage with the hardware.

    Are the antiX kernels derived from Debian’s kernels? Those are free enough for this purpose. If they are not Debian derived, do you know if they contain any non-free components? If they do, it’s not a problem, I can switch to Debian kernels or the Linux-libre kernel easily, just wanted to check. You do have a massive number of kernels in the repos, I don’t think I’ve ever seen that many at one time.

    Attachments:
    #47401
    Forum Admin
    anticapitalista
    Helpful
    Up
    0
    :D

    antiX kernels are built directly from source.
    We do not ‘deblob’ anything (unlike Debian) so I guess it will have some non-free elements.
    I might be wrong on this though.

    Philosophers have interpreted the world in many ways; the point is to change it.

    antiX with runit - leaner and meaner.

Viewing 15 posts - 1 through 15 (of 16 total)
  • You must be logged in to reply to this topic.