Non-UNIX Folder Structure for (some) packages

This forum is dedicated to new ideas, suggestions and proposals.

Non-UNIX Folder Structure for (some) packages

Postby roti » Feb 27th, '15, 00:30

Hi,

I recently stumbled upon Gobolinux and I must say I find the idea behind it very good. It simplifies a lot of things when it comes to package management, my favourite being the handling of multiple versions of a piece of software (library or app).

There is certainly a friction caused by the UNIX folder structure with apps which were not designed with it in mind. And it's the packagers job to adapt the software to the distro's folder structure and solve eventual problems that raise out of that. I have encountered two such problems, the details of which are not important (one with the tomcat server, the other with libreoffice). I suspect Gobolinux packagers have a much easier job due to their folder layout.

So here's the idea: what if we would stop adapting software which was not designed for the UNIX structure? So, instead of spreading, for example, eclipse throughout /usr/bin, /usr/lib64 and so on, we could just put it in /opt/eclipse-platform/4.3.1-8.mga4.x86_64. That should work right?

I deliberately picked eclipse as an example, because it is designed to be just copied on the system instead of being installed (which is brilliant IMO: you download it, put it somewhere and it just works, no installations and configurations). By laying out eclipse's files differently one is essentially fighting against the stream. There's an additional complexity in the system (keeping track of the original and adapted folder structure) with (imo) questionable benefits.

Also many applications have today an automatic update feature, and there is high chance that it won't work anymore if you have changed its folder layout. So to have a consistent behaviour, the packager should disable that functionality or adapt it. If we leave the application with its original folder structure, this problem just goes away.

Looking forward to your thoughts on this.
Răzvan
roti
 
Posts: 31
Joined: Nov 7th, '11, 10:05
Location: Bucharest, Romania

Re: Non-UNIX Folder Structure for (some) packages

Postby benmc » Feb 28th, '15, 06:03

Hi Roti,

A downside I see is the system may have at once more than 1 version of any given package in use.

Eg: one application needs and uses " libmyspecial 2.0.2-2.mga5.i586 ¨
and another that you have running at the same time needs and uses " libmyspecial 3.7.2-5.mga5.i586 ¨
Yes, they are both drawn from their respective folders but I think the service that controls the library interaction could be jumping through some pretty big hoops to keep the 2 applications stable.

The doubling up of libraries would also give rise to that "Windows" feeling of bloatware.
I quite like not having to keep increasing my / drive, unlike on my Windows machine.

just my 2 cents.
benmc
 
Posts: 1175
Joined: Sep 2nd, '11, 12:45
Location: Pirongia, New Zealand

Re: Non-UNIX Folder Structure for (some) packages

Postby roti » Feb 28th, '15, 15:42

I see the possibility of having multiple versions of the same library as an advantage, not a downside. Indeed solving library lookups will be harder (if this is what you mean), but I don't think it's a hard problem. It's just another dependency problem. I come from Java, where maven and osgi are doing pretty well in this area.

I would not bother for space issues, at least not in a desktop oriented distro. The same goes with memory, which is cheap. I do mind, if something is slowing my system down, with CPU consumption and IO, but that is not something the OS can control. In Windows "bloatware" (and other kind of *wares) thrives mostly because of culture. App stores do improve the situation a little bit.

Răzvan
roti
 
Posts: 31
Joined: Nov 7th, '11, 10:05
Location: Bucharest, Romania


Return to Ideas and suggestions

Who is online

Users browsing this forum: No registered users and 1 guest

cron