211–220 of 324 posts
Earlier quoted context omitted.
You have make call the platform specific build systems.
I have done so in the past. This leads to a lot of duplication though.
Earlier quoted context omitted.
> jealous, insisting that every language has to conform to their way of doing things Let's ignore for a moment all your baseless assertions and focus on the following question: how do you ensure that a build is reproducible if you have no control on which required dependencies are downloaded by a build system which requires root access? Is jealousy the only explanation that comes up to you?
you can use a tool like snap or appimage to pull down the newest full release of your software.. at least then, all the dependancies are 'bundled' into the image, and your not having people go randomly install crap from around the internet with no real way to update.
The .sdeb format packages up sources and build scripts into one atomic, build-able unit.
Terrible article IMO. Hadoop is an awful mess, but it has nothing to do with Docker, which is simplistic in comparison. "Ever tried to security update a container?" Yes, I have! In fact you can maintain patch compliance in a container pretty much the same way you'd maintain a VM or bare metal Linux installation!
The real point the author is making is that many times containers are misused to paper over problems like lack of reproducibility, dependency hell, etc. They aren't reproducible, certainly not by you. If they were you'd not need the container in the first place, or you could build your own easily. So for this kind of misuse, the analogy to Tucows Windows 95 shareware is pretty close.
Hadoop and Docker are just the examples to make the point. And they are good enough ones, because I could understand exactly what the author meant. There are certainly hundreds of other examples.
Earlier quoted context omitted.
Installing multiple versions is possible, given proper semver and good arguments for it: There are quite a few libfoo5, libfoo6, libfoo7 packages. What isn't and shouldn't be possible is installing libfoo 6.6.5 and 6.6.6 at the same time, because those should be compatible. And not being easy to replace (i.e. ABI- and API-compatible) means that security and bug fixes will be missed. Of course this is work for applica…
I think these are noble but naive approaches - we have been developing software for a few decades now and sometimes the software is not compatible without the developer knowing it. You should be able to use whichever version of the software you need.
Earlier quoted context omitted.
Not so obviously as you might think. But, if they are going to do it, they should clearly do it well
Right, but my experience is that Java (and a few others) have succeeded in this space. I actually wish that I could use maven to install system software rather than having to rely on something like apt.
Earlier quoted context omitted.
Because at least with make install you can have some trust in the delivery method, ie encrypted git or whatever. If you use just plain http....
So wget https://example.com/installer.tar.gz ; tar -xvzf installer.tar.gz; cd installer; make install is okay for you? But curl https://example.com/installer.sh | bash is not? Why?
Earlier quoted context omitted.
You missed the bigger point. Just look at the popular images on Docker hub. A lot of them involve messy build steps, including downloading binaries or source tarballs without verification. It's often hard to know which dependencies a Docker image has, and therefore hard to track vulnerabilities and redeploy fixed images. A lot of docker containers end up either running for a long time, or get rebuilt and redeployed o…
"But we need to figure out the tooling and ecosystem story to build, verify and update container deployments securely." Already done: Solaris zones. Available in the SmartOS distribution near you. Combine with OS packaging, imgadm and vmadm commands for maximum impact.
How does provide visibility into every dependency inside an image? Especially when using 3rd-party-maintained images that consist of significant hours of work per image to get the image to work.
(BTW., I built "live CD images" for use in physical and virtual machines since ~2001, using tools such as mklivecd, livecd-tools etc.).
Earlier quoted context omitted.
You have make call the platform specific build systems.
What's the point in a project that only uses a single build system? You're essentially getting nothing out of make except indirection. Might as well just have a build.sh at the root of the repo.
The thing you're getting is some familiarity, I think (because of the indirection). It's sort of like using a `package.json` for the scripts section, but you get to have comments, and there's less other random stuff in there.
I definitely understand why many would think this is over-kill though. A proper readme is probably just as good/better.
Earlier quoted context omitted.
Who still uses Hadoop anyway? https://spark.apache.org/ https://www.iguazio.com/data-science-post-hadoop/
Spark is worse because you need Scala as well as regular Java. I've tried building it for my day job, I would rather have a colonoscopy without sedation. It's more pleasant and dignified.
The only real system dependencies are Java8, maven and texlive (and Python/R if you build for that). Then it's `make-distribution.sh` with the appropriate flags. Scala and everything else that is needed is downloaded by maven. The resulting directory is self-contained assuming you have java8 runtime on your target machine.
Earlier quoted context omitted.
> Oh, check out Nix Nix is a non-sequitur. Nix requires specific packages and package versions to be specified, and Nix requires the build process to be "free from side effects". That fails to address both problems stated by the OP, and actually try to reimplement what Debian's package building process already does. Other than trying to publicize Nix, your comment adds nothing to the discussion.
>how do you ensure that a build is reproducible if you have no control on which required dependencies are downloaded by a build system which requires root access? By having control over which required dependencies are downloaded. As Nix does. Why would you settle for not solving that problem? Sorry to hear you don't think my comment adds to the discussion, but I'd disagree
Again, Nix adds nothing to the discussion. The problem stated by the OP was caused by the (broken) way that the custom build system of a specific package was designed to work, which failed to adhere to the standard practices enforced by Debian's packaging process.
If the packagers of said software project followed Debian's practices then the problem wouldn't exist.
You're parroting that Nix also enables users to specify dependencies. Ok, so it works just like any other package system. What does that have to do with the problem being discussed? Nothing.