Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » U++ community news and announcements » U++ 2017 beta
Re: U++ 2017 beta [message #47315 is a reply to message #47312] Wed, 04 January 2017 08:08 Go to previous messageGo to previous message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
MrSarup wrote on Wed, 04 January 2017 08:28

The Linux world stopped working with a "tar ball only" approach several decades ago, when the idea of package managers got popular. It appears that this is not understood here. Let's say, will the Linux community announce the following for Centos:

yum -y install upp

No! If not, that idea is garbage!!! As simple. Period.

This is a classic example of the restrictive development process of U++ that centers around Mirek's taste, time, approaches, etc.
The reason is that he is alone, or predominantly working on this project and there are not many active developers available.


Sorry there, but the must be the most wrong thing I heard all year.

Linux has moved on decades ago but hasn't really made any progress.

Software distribution on Linux is the worst out of all OSes and has always been so. It is baby level super primitive stuff. It is so bad that you CAN NOT do software distribution for Linux as an entire platform. You can't. Nobody can. Not a single developer. It is just that hard.

So people have adapted (instead of fixing Linux) and moved part of responsibility downstream. The developer provides buildable sources for one environment, often using automake and friends to maximize compatibility and completely different people not affiliated with the developer will choose when/if/how to package for their distribution. And if the developer updates, he can't push an update. The external packager chooses to update if he wishes.

Sure, there are exceptions, but in general this is the work-flow. Otherwise, even a hello world application would take you literally months to package. There are over a dozen very popular Linux distros. And over another 50 in somewhat wide use. And hundreds more that are stable. And hundreds more. There are many package formats. For each version even the most common .so can change, so everything needs to built. And even if you packaged for all, some people still expect a tarball or they will call you out for not being OSS enough.

Even if you manage to create a package that works for multiple Linux versions, half of them won't accept it into their repo. You need to set up your custom third party repo or go back to tarballs. So you have to set up an maintain a dozen or more servers. Users need to add the custom repo.

So yeah, software distribution on Linux in near impossible as a developer and this stupid situation happens only on Linux.

The only mistake that U++ does in its distribution of tarballs is not using standard tools and automake. The auto* tools work, but ideologically, they are the worst thing ever. They rely on decades worths of tips and tricks, clever ways to detect Linux differences and do a million things for even the simplest ./configure. And this is bad because you shouldn't have to have such a mammoth of an architecture just to build. Something that needs such effort to build is bad.

Period.

The build system I'm working on right now knows this. It is designed to build arbitrarily complex projects with a short list of folders and a couple compilation options. The entirety of autoconf and friends' wisdom is discarded, not because it is bad, but because it shouldn't be needed. There is configure, make and make install. There is just on command and it works.

I think that maybe umk tried to do something similar.

Oh, and if you think I'm wrong, I dare you to prove it. Spend month trying to find a good method for Linux for my own needs and there is none.

But if you think there is, please show me the link to the standardized no-hassle tool that allows you to package a piece of software once and it will produce one or multiple binary packages capable of working out of the box (and install dependencies) on all of Linux.
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message icon14.gif
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: upp-10502-winxp32-compiled
Next Topic: On-line meeting before 2017 release
Goto Forum:
  


Current Time: Sun May 05 01:20:41 CEST 2024

Total time taken to generate the page: 0.03828 seconds