• P (unregistered)

    Until you hit the situation where installing one dependency uninstall another one because of version conflict.

    Also, he can't inspect the output of every install to determine better stuff to do? That's TRWTF.

  • why is it even there (unregistered)

    (( first++ ))

  • ZPedro (unregistered)

    "It's not a WTF if you know it's a WTF": look, Remy, don't start getting into paradoxes like that (see also: "all rules have exceptions", invoked in biology or law, among other fields) because you don't know what you're getting into. That way lies madness, madness I say.

  • bvs23bkv33 (unregistered)

    you can power a medium town if you attach a generator to Ian Murdock's body rotating in his coffin

  • keb (unregistered)

    Trying all the combinations of a set is O(n!), so this shouldn't work in all cases :)

  • Robert (unregistered)

    Manual apt-get isn't too difficult. From memory ...

    1. Copy (Rsync) the contents of /var/lib/apt/ from an internet connected PC (after apt-get update).
    2. Use apt-get --print-uris to decide on the deb files you need to download.
    3. Drop your downloaded .deb files into /var/cache/apt/archives/
    4. Run apt-get install/dist-upgrade or whichever.
  • Steve (unregistered)

    Do we provide absolution or do we burn with cleansing fire?

    Personally I favour forgiveness, but then again I'm in a good mood at the moment ...

  • P (unregistered)

    Should Remy feature this comment? Depends.

  • Foo AKA Fooo (unregistered)

    "It's the brutest of force solutions" -- come on, please! Here we have a brillant opportunity to implement bogosort in the wild and you shun it:

    • Install all packages in a random order.
    • If it fails at any point, uninstall them all and try again.

    Beautiful nondeterministic O(n!) instead of that shabby deterministic O(n²)!

  • rpm hater (unregistered)

    dpgk accepts multiple deb packages at once and the system will resolve dependencies itself. (so dpkg -iR . should just work).

    But for rpm packages it is not the case. I did once write a very similar script for rpm packages.

  • siciac (unregistered)

    Store the files to process in an array.

    Stop looping if your array is empty. Stop looping and raise an error if an iteration does not result in a successful install.

    But then burn down the array by removing packages as they install successfully.

  • Robert M (unregistered)

    Arguably, another way to fix this would be to use apt-offline, since it's designed for offline systems and thus handles the dependencies as well!

  • Tim (unregistered)

    If the time taken to do the sudo and report "package already installed" is small compared to the time to install a package then this solution is perfectly reasonable and might well not warrant spending more time to build a more "clever" solution . The "big oh"-ness of an algorithm isn't necessarily relevant for small numbers of n

  • (nodebb)

    "It's not a WTF if you know it's a WTF. If you've been doing this job for a non-zero amount of time, you have had a moment where you have a solution, and you know it's wrong, you know you shouldn't do this, but by the gods, it works and you've got more important stuff to worry about right now, so you just do it." Thanks for this. I've felt that's been missing since I first started reading in 2008.

  • (nodebb)

    I say this is a WTF because as others noted, with a few different lines of script a much more efficient solution can be accomplished, meaning this is not a case of desperate measures for desperate times.

  • (nodebb)

    The time complexity may be O(n^2), but the log-file complexity might be O(n^3) if the error messages for missing dependencies lists all the dependencies.

  • PotatoEngineer (unregistered)

    It's still a WTF if you know why, how, and to-what-degree it's a WTF.

    Because someday, maintenance will pass to some other poor sod, and they're not going to have access to your carefully-constructed self-serving tower of excuses. If you manage to come back and fix it right (HA!), then it's not a WTF. But the moment you expose that code to anyone else, it's a tiny WTF, and the moment anyone else has to understand it to get something done, it's a full-blown WTF.

  • sizer99 (google) in reply to PotatoEngineer

    As long as it's documented, it's no longer a 'WTF is this mess?' You know exactly what mess it is. In my code written under crazy schedule you will stuff like find '// TODO: handle (edge case) - no time right now'. As such, this script is missing 3 lines of 'yes, I know, but here's the situation and I can't waste any more time on this' at the top.

    And then the WTF is that he didn't know dpkg would do this much faster and cleaner - it's always the stuff you don't know!

  • ZZartin (unregistered)

    This certainly seems like a case where just using a janky solution for what should be a rare occurrence anyways is fine.

  • richarson (unregistered) in reply to rpm hater

    Are you sure? How long since you tried rpm?

    In my experience (CentOs 5/6/7), 'rpm -Uvh' does exactly what you say 'dpkg -iR' does. But, if there is a missing denendenciy rpm won't install any of the .rpms you supplied.

    On the contrary, the few times I found someone used 'dpkg -i *.deb' (notice the lack of '-R'), I had to do 'apt -f install' afterwards to install the missing dependencies. This was probably on Ubuntu systems, Debian and other derivatives might do it differently.

  • Simon (unregistered)

    The difference between a WTF and an evil hack is that the evil hack is is accompanied by half a page of comments explaining "Why TF". Because if you have to resort to unholy abominations, at least make sure the next guy knows what it's all about — because the next guy could be future-you.

  • (nodebb)

    A WTF you know is a WTF is not a WTF because you don't go "WTF" when you encounter it because you already know too, too much.

    But clearly the thing to do here would be to construct a de Bruijn sequence from the list of dependencies and then just run through that.

  • Greg (unregistered) in reply to Watson

    Upper limit ceil(n*(n-7/3)+19/3)

    http://oeis.org/A062714 Minimal length of a sequence with terms from {1, 2, 3, ..., n} which contains, as a subsequence, each possible ordering of the n symbols 1, 2, 3, ..., n.

    No optimal solution is known.

  • Skandar Graun (unregistered)

    Oh, my. Someone seems to have forgotten the subtle art of ssh tunneling.

    No, I don't mean just the port forwarding, that can be disabled on the jump hosts in between, or at least on the remote itself.

    But as long as stdin/out is transmitted via SSH, all you need is a netcat to:

    1. Create an stdin/out tunnel to make your local sshd accessible on the remote host
    2. SSH back from there to setup a normal ssh port forward, in order to
    3. Make a local squid proxy available on the remote host

    So:

    1. Tunnel your sshd to the port 2222 on the remote: ncat -e '/usr/bin/ssh user@remote /usr/bin/ncat -lp 2222' localhost 22

    If you need more jump-servers, then chain the ssh commands: 'ssh user1@remote1 ssh user2@remote2 ... ncat -lp 2222'.

    This 'tunnel' lasts only for one connection, so it's not enough for http proxying, but definitely enough for ssh-ing back:

    1. On the remote (in a 2nd session): ssh -C -p 2222 -L 3128:127.0.0.1:3128 localuser@127.0.0.1

    So your whatever traffic hits the 3128 on the remote, it'll be forwarded to 127.0.0.1:3128 from your local machine. Please start a squid in advance to handle that :).

    1. And then in a 3rd session on that remote host you have a fully usable http proxy available: export http_proxy="http://127.0.0.1:3128" apt-get install whatever docker pull whatever w3m https://thedailywtf.com ...

    About a decade ago we used this trick quite frequently at a respectable telco company who liked to 'harden' their systems almost to the complete unusability.

  • Yep (unregistered)

    There is always a first attempt. Never a zeroth.

  • (nodebb)

    There's another minor WTF imho, the "count" variable is never reset when it should actually be set to zero with each deb package. This is done only initially, before the loop across the files matching "*.deb" starts. So the variable will reveal the total number of attempts across all deb packages eventually. Not sure whether that's very meaningful.

  • (nodebb)

    The only true problem with this approach is that there's nothing more permanent than a “temporary” fix.

  • Little Bobby Tables (unregistered) in reply to dkf

    Depends on whether you've got your part of the application running (through various short-cuts like this) and now you're waiting for someone else to finish their bit. Then you can look all smug and the project manager likes you (especially when you tell him you're "catching up with some of the documentation that [previous cow-orker] failed to do." Go back and enjoy polishing the bumpers and painting those go-faster-stripes.

Leave a comment on “Should I Do this? Depends.”

Log In or post as a guest

Replying to comment #:

« Return to Article