Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid replacing system packages with SBo ones #1

Open
denydias opened this issue Apr 7, 2016 · 2 comments
Open

Avoid replacing system packages with SBo ones #1

denydias opened this issue Apr 7, 2016 · 2 comments

Comments

@denydias
Copy link

denydias commented Apr 7, 2016

Hi @McDutchie,

Thank you for this great little script.

The check_for_updates() is great! It does almost everything I need to keep my sanity with SBo package upgrades. That is, to get a list of upgrading package candidates respecting its dependency order for the build time. sbopkg fails miserably in this task, as its package upgrade check function just detect what packages should be upgraded in the alphabetic order! If one try to run this queue without sorting it by dependency first, it'll bite for sure. Sorting that queue is a pain when there's lots of packages to upgrade.

sbodep -c almost fix that, with one exception: it doesn't exclude the packages that may already be installed in the system. When check_for_updates() runs, it calls almost in the end resolve_deps(). This functions does what it's supposed to: get the package dependencies recursively. But this poses a problem if one have a package already installed.

Let me show you what I'm talking about with some examples.

$ sbodeps -c
[...suppressed output]
gst-plugins-ugly
gst-python
ffmpeg
guvcview
[...suppressed output]

ffmpeg and its friends are a dependency to guvcview.

Now look at this:

$ ls /var/log/packages/ | grep ffmpeg
ffmpeg-2.8-x86_64-1alien

Turns out that ffmpeg is already installed on that system. In that case, the AlienBob's package. I don't need to rebuild it, and I don't want to replace that package with a SBo one. sbodep's resolve_deps() doesn't take that into account. It just solve the dependencies by checking which package from SBo is required and is not already installed.

To fix that, I came up with an external, poorly written script. Here it goes:

#!/bin/bash
IFS=$'\n'
SBODEP=( $(sbodeps -c 2> /dev/null) )
PKGLOG="/var/log/packages/"

# If verbose, print a header
[ "-v" = "$1" ] && printf "U | %-20s | %-25s | %-25s\n" "UPDATE CANDIDATE" "SYSTEM PACKAGE" "SLACKBUILD PACKAGE"
[ "-v" = "$1" ] && printf "%.0s-" {1..80} && echo

# Main loop
for i in ${SBODEP[@]}
do
  update=false
  # Check for installed packages
  sysinst=$(ls $PKGLOG | grep "^$i\-" | grep -v "ponce$\|_SBo$")
  sboinst=$(ls $PKGLOG | grep "^$i\-.*ponce$\|^$i\-.*_SBo")
  if [ -z "$sysinst" ] && [ -z "$sboinst" ] || [ -n "$sboinst" ];then
    # Package is not a system one or was not installed from SBo
    update=true
  fi
  if $update;then
    # If verbose, print that package is a candidate to upgrade from SBo
    [ "-v" = "$1" ] && printf "+ | %-20s | %-25s | %-25s\n" "${i::20}" "${sysinst::25}" "${sboinst::25}"
    # No runtime arguments, add to queue
    [ "-v" = "$1" ] || echo $i
  else
    # If verbose, print that package is a system one, DO NOT upgrade from SBo
    [ "-v" = "$1" ] && printf "  | %-20s | %-25s | %-25s\n" "${i::20}" "${sysinst::25}" "${sboinst::25}"
  fi
done

Let's see what it does:

$ sbosafeup -v
U | UPDATE CANDIDATE     | SYSTEM PACKAGE            | SLACKBUILD PACKAGE       
--------------------------------------------------------------------------------
[...suppressed output]
+ | gst-plugins-ugly     |                           | gst-plugins-ugly-0.10.19-
+ | gst-python           |                           | gst-python-0.10.22-x86_64
  | ffmpeg               | ffmpeg-2.8-x86_64-1alien  |
+ | guvcview             |                           | guvcview-2.0.2-x86_64-1po
[...suppressed output]

Hummm! What does that mean?

gst-plugins-ugly, gst-python and guvcview itself were installed from SBo, thus they are good candidates to the queue, which is shown by the + sign. But ffmpeg is present as a system package (well, not really a system one, but it's already there anyway), so we can let it out of the party and gets no sign.

With that information, what the sbopkg queue itself will look like? Let's see:

$ sbosafeup
[...suppressed output]
gst-plugins-ugly
gst-python
guvcview
[...suppressed output]

Look! No ffmpeg! \o/

Well, I'm talking and talking here just to tell you that, if you want to, there's room to improve your nice little sbodeps. This is not a real issue nor a feature request, although it would be nice to see this implemented.

My script is crap and do not cares about any kind of optimization. It just works. I think that you are much more capable to improve it. ;)

Thank you!

@denydias denydias changed the title Avoid replace system packages with SBo ones Avoid replacing system packages with SBo ones Apr 7, 2016
@denydias
Copy link
Author

denydias commented Apr 7, 2016

Em qui 07 abr 2016, às 15:27:40, Martijn Dekker escreveu:

sbodeps provides for this. Instead of sbodeps -c, try sbodeps -cn.
The -n option makes the resolve_deps function honour installed non-SBo
packages so they are not rebuilt and replaced.

This is not done by default because non-SBo packages are not guaranteed
to be compatible (they may be compiled with different options or
features from the one SBo packages expect), but in most cases it's
unlikely to be a problem.

  • Martijn

I'm aware of -n option. From what I could see, it outputs a queue file with every single SBo package installed in the system. This is quite different of what I'm proposing, which is to provide a queue file with just the upgradable packages, i.e. the ones with newer versions in the SBo repo.

Anyway, it's fine. sbodeps already does its job pretty well. ;)

@McDutchie
Copy link
Owner

Op 08-04-16 om 01:08 schreef Deny Dias:

I'm aware of -n option. From what I could see, it outputs a queue file
with every single SBo package installed in the system. This is quite
different of what I'm proposing, which is to provide a queue file with
just the upgradable packages, i.e. the ones with newer versions in the
SBo repo.

Yes, I removed that comment - brain fart on my part. When I find some
time I'll look into the improvement you're suggesting. Thanks for the
report.

  • M.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants