how to prevent nosystemd packages to be overwritten with new testing ones ?

Forum Forums antiX-development Development how to prevent nosystemd packages to be overwritten with new testing ones ?

  • This topic has 10 replies, 3 voices, and was last updated May 30-2:25 pm by sspade.
Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #10554
    Member
    Avatarsspade

    Hi,
    I have AntiX setup running with testing. Recently gvfs* packages are proposed to be updated with systemd new vesion ones from testing. So if I want to keep the nosystemd consistency, I cannot accept that.

    Here is the report from apt-notifier :
    gvfs (1.36.0-1.0nosystemd1 => 1.36.1-1)
    gvfs-backends (1.36.0-1.0nosystemd1 => 1.36.1-1)
    gvfs-common (1.36.0-1.0nosystemd1 => 1.36.1-1)
    gvfs-daemons (1.36.0-1.0nosystemd1 => 1.36.1-1)
    gvfs-libs (1.36.0-1.0nosystemd1 => 1.36.1-1)

    Is there a parameter somewhere to prevent this kind of updates ? Something that says that nosystemd packages take precedence over testing ones, even if testing version is greater than nosystemd one.

    Regards

    #10555
    Forum Admin
    anticapitalistaanticapitalista

    It is better to wait until the new nosystemd built packages hit the antiX nosystemd repos.
    I have the packages built and will send them to our repo manager.

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

    antiX with runit - leaner and meaner.

    #10556
    Member
    Avatarsspade

    Thanks for your quick answer.
    Here is how it happened:
    I noticed that gvfs has been broken on my machine because network discovering was not working anymore in Thunar.
    Then I discovered gvfs-bakends was not installed, probably uninstalled with an upgrade from apt-notifier.
    When I tried to install it, I noticed the problem with systemd and nosystemd versions, and discripances in Debian database. So I needed to uninstall plenty of dependant packages and reinstall them with the nosystemd version, to be finally able to install gvfs-bakends with the nosystemd version.
    Don’t you think the actual mechanism is a bit dangerous ? The problem I faced could occur again at anytime.
    I have the feeling that systemd is trying to eat nosystemd.
    I am not in a hurry to get the very up-to-date packages so I don’t care if there is a delay between the update of systemd repo and the nosystemd repo, but I like the idea to be warned about updates and to make them through a friendly applet like apt-notifier. If I should check every single package and every single version on each update process (~1 a day), the process will become much more tedious. Moreover, if I need an update about a particular package without nosystemd problem, I should make it manually.
    I am not very familiar with all repo capabilities, but don’t you know a way to make the update mechanism safer, for example with a setting file in /etc/apt/preferences.d ?
    Or maybe setup a full separate AntiX repo that point to the regular debian repo, except for nosystemd packages ?

    Regards

    #10557
    Forum Admin
    anticapitalistaanticapitalista

    Using Testing and/or sid repos is not advised if you worry about safety. You should probably stick to stable/stretch.

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

    antiX with runit - leaner and meaner.

    #10567
    Member
    Avatar736b69646f6f

    “Is there a parameter somewhere to prevent this kind of updates ? Something that says that nosystemd packages take precedence over testing ones, even if testing version is greater than nosystemd one.”

    adding this stanza in /etc/apt/preferences might be effective if you are using debian testing repostory. I didn’t test it though.
    The idea is, unless coming from stable repo (which is permanently disabled in your sources.lists) any matching packages will not be considered as upgrade candidates.

    Package: *0nosystemd1*
    Pin: release o=Debian,a=stable
    Pin-Priority: 990

    #10573
    Member
    Avatarsspade

    The word “safety” has several meanings.
    In terms of “buglessity”, I have the feeling that the testing repo is satisfying to me. I am coming from Ubuntu distros, so the version level of Debian packages belonging to the testing repo is more or less equivalent to the Ubuntu ones. I may change my mind later with bad experiences, but I am coming from this point.
    Safety has another meaning that I can experience right here and right now, which is the consistency of repo database. It is fair enough to want to use only one database ie stable, testing or unstable. But do we really have this choice ? I am using a recent Firefox (>58) with a new set of plugins (old ones are not compatible with the new version). To get the last version of it, I added the unstable repo in /etc/apt/sources.list.d/debian.list:
    deb http://ftp.fr.debian.org/debian/ unstable main
    To keep priority on testing packages, I added the file /etc/apt/preferences.d/unstable:
    Package: *
    Pin: release a=unstable
    Pin-Priority: 50
    My main repo is still testing, but I can install Firefox (non ESR) and get updates about it.
    I forgot to tell you that a found a weird dependency of the package gvfs-backends to libnfs8, which is not in the testing repo but in the stable one. So I added the following line in /etc/apt/sources.list.d/debian.list :
    deb http://ftp.fr.debian.org/debian/ stable main contrib non-free
    I supposed that priority of testing packages over stable ones is automatic, due to greater versions.
    On your advise, I added /etc/apt/preferences.d/01nosystemd:
    Package: *0nosystemd1*
    Pin: release o=Debian,a=testing
    Pin-Priority: 990

    (in my case, it is a=testing rather than a=stable, isn’t it ?)

    Finally my repos are :

    
    $ inxi -r
    Repos:
      No active apt repos in: /etc/apt/sources.list 
      Active apt repos in: /etc/apt/sources.list.d/antix.list 
      1: deb http://nl.mxrepo.com/antix/testing testing main nosystemd
      2: deb-src http://nl.mxrepo.com/antix/testing testing main nosystemd
      Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
      1: deb http://ftp.fr.debian.org/debian/ stretch-updates main contrib non-free
      Active apt repos in: /etc/apt/sources.list.d/debian.list 
      1: deb http://ftp.fr.debian.org/debian/ stable main contrib non-free
      2: deb http://ftp.fr.debian.org/debian/ testing main contrib non-free
      3: deb http://ftp.fr.debian.org/debian/ testing-updates main contrib non-free
      4: deb http://ftp.fr.debian.org/debian/ unstable main
      No active apt repos in: /etc/apt/sources.list.d/onion.list 
      Active apt repos in: /etc/apt/sources.list.d/opera-stable.list 
      1: deb https://deb.opera.com/opera-stable/ stable non-free #Opera Browser (final releases)
      Active apt repos in: /etc/apt/sources.list.d/teamviewer.list 
      1: deb http://linux.teamviewer.com/deb stable main
      2: deb http://linux.teamviewer.com/deb preview main
      No active apt repos in: /etc/apt/sources.list.d/various.list

    I made #apt-get update and it looks to work !
    Today the nosystemd packages gvfs* have been updated (probably from you, thanks) to the same version as systemd ones, so I cannot really say that if systemd version is greater, I still keep nosystemd ones with the update mechanism and the new setting.
    With the new version, there is no more dependency on libnfs8, so I can probably remove the stable repo.

    To increase the consistency of the AntiX repos, it would be great to automatically add /etc/apt/preferences.d/01nosystemd in the AntiX installer, wouldn’t it ?

    Thanks for your work !

    #10574
    Forum Admin
    anticapitalistaanticapitalista

    To increase the consistency of the AntiX repos, it would be great to automatically add /etc/apt/preferences.d/01nosystemd in the AntiX installer, wouldn’t it ?

    No it wouldn’t, and if you do so, you’ll see why.

    Debian is not Ubuntu so mixing repos is not a good idea (to say the least). You do realize you have a mixture of stable, testing and unstable in your repos.list, don’t you? Of course, it is your computer and you are free to do what you like, include picking up the broken pieces when it inevitably breaks.

    Added: If you wish to try the 01nosystemd changed suggested but not tested by 736b69646f6f, do so and let us know the outcome.

    • This reply was modified 2 years, 2 months ago by anticapitalista.
    • This reply was modified 2 years, 2 months ago by anticapitalista.

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

    antiX with runit - leaner and meaner.

    #10578
    Member
    Avatarsspade

    OK, as far as I understood, there are 2 different subjects:

    1/ mixing debian repos
    Your advise is great and I can easily respect the rule of not mixing repos.
    I don’t need the stable repo, so I can remove it.
    The only reason I added the unstable repo is to install Firefox>57. I can live with the only testing repo with manually installing Firefox. Or maybe you have another solution to suggest to me to be able to get Firefox 60 and updates from debian database ?

    2/ systemd and nosystemd packages
    The experience showed us they are mixed up and nosystemd packages could be contaminated with systemd ones. It is like sup-repos. On my side I know how to avoid the problem in the future because of your solution. But basic users could be faced to the same problem and:
    – they could switch from nosystemd to systemd without realizing
    – they could conclude “AntiX is great but nosystemd packages update mechanism is unstable and I switch to systemd because it is more simple”
    – they could conclude “AntiX is not great because the repo database is unstable out of the box”
    Always setting up the file 01nosystemd could be a reliable solution to definitely separate systemd and nosystemd packages. It is just a suggestion with the objective to improve AntiX, but maybe I miss arguments that would explain that it is not a good solution.

    Regards

    #10579
    Forum Admin
    anticapitalistaanticapitalista

    1. You can install latest firefox via the packageinstaller app.
    2. First of all, that is how testing/sid works. It is inherently unstable (or better put – a moving target). Thus, basic users should not use testing or sid
    My advice for those using testing/sid is to upgrade via the terminal, and note if any nosystemd debs are going to be replaced by systemd ones. If that is the case, just say No to the upgrade and wait a day or so until we at antiX repackage them and upload them to our repos.

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

    antiX with runit - leaner and meaner.

    #10583
    Member
    Avatar736b69646f6f


    On your advise, I added /etc/apt/preferences.d/01nosystemd:
    Package: *0nosystemd1*
    Pin: release o=Debian,a=testing
    Pin-Priority: 990

    Hi. What you typed is different from what I suggested. You rule instructs “prefer versions of *nosystemd0 packages from testing”. This would yield the same result as not having the rule at all because you’re already, and only, sourcing testing repositories.

    A review:

    Testing repositories are active in sources lists.
    Stable repositories are not, and will not be activated in the future.
    The rule stanza “prefer versions of *nosystemd0* packages from STABLE” is intended as an “impossible to satisfy” rule, toward preventing dpkg from treating any newly available matching packages from the debian testing repository as eligible upgrade candidates.

    #10595
    Member
    Avatarsspade

    Sorry I am suddenly a bit confused about my config.
    Is the debian testing repo necessary ? Is the antix testing repo enough ?
    In other words, should I delete the line:
    deb http://ftp.fr.debian.org/debian/ testing main contrib non-free

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