Filesystem abstraction in package management

pedepy · 2008-06-28 18:21:59

Hey all .. just a thought I had the other night, wanted to share and get opinons on it.

Probably not anything new, but I was wondering why some kinda filesystem abstraction layer couldnt be implemented in a package management system such as libalpm/pacman ? For instance, instead of storing information as 'absolute' directories, one could store data such as $appdir or $bindir or $libdir, so on and so forth. Information as to where that points to is stored in the config files locally, for any particular distro.

Potentially one particular dev could package a tarball containing a PKGBUILD with info as to how to build & install the software, along with dependencies, and then locally the package management system takes care of installing everything in the right manner, building the source with the right tools / configurations if needed.

Im not sure if im explaining this right, but anyway, let me know what you guys think. Maybe there are other factors in play that prevent something like that from being implemented. i dunno ?

Hohoho · 2008-06-28 18:53:53

Well, for one, if you switch those variables at one point and have half your packages installed one way and the other another way all hell could break loose, unless you include appropriate path handling to pacman too. But then it just gets hell of a lot more complex, and Arch is all about KISS.

pedepy · 2008-06-28 19:06:16

well i dont understand why'd you wanna change those 'half way' in .. ?

Point is, if one distro chooses to install all apps to '/opt/' and another one to '/usr/bin', and yet another one to '/applications' (breaking the standards, of course), then the PKGBUILD would still work on all 3 of those layouts.

Of course if you decide to change your filesystem hierarchy on an existing install all hell would break loose ..

I guess a better way to get my point across might be that 'all info pertaining to filesystem hierarchy used to direct binaries, libs, configurations & symlinks should be handled by the package management system, not the package files themselves'. Does that make a tad more sense now ?

Then again, just getting everyone to agree & follow a standard hierarchy in the first place would also solve that problem.

Last edited by pedepy (2008-06-28 19:07:13)

B-Con · 2008-06-28 22:47:43

I think I see exactly what you're saying, but realistically, what's the benefit to making it different? Most users would choose the same layout, probably the same one we have now.

ibendiben · 2008-06-28 22:50:10

pedepy wrote:

Then again, just getting everyone to agree & follow a standard hierarchy in the first place would also solve that problem.

But it stops evolution in a way... It is like the bible telling you what to do, because it's THE (only) GO(o)D way to do it.
We find 1000 years later that this standard is outdated and stump (well I do ). It makes people narrow minded, and keeps you from moving on.
So... I like your idea...
At least thinking about things and exploring the other possible ways makes you wiser... -> go on!

B-Con · 2008-06-28 22:59:27

ibendiben wrote:

pedepy wrote:
Then again, just getting everyone to agree & follow a standard hierarchy in the first place would also solve that problem.
But it stops evolution in a way... It is like the bible telling you what to do, because it's THE (only) GO(o)D way to do it.
We find 1000 years later that this standard is outdated and stump (well I do ). It makes people narrow minded, and keeps you from moving on.
So... I like your idea...
At least thinking about things and exploring the other possible ways makes you wiser... -> go on!

This has nothing to do with any sort of absolute right/wrong or any evolution. It's about offering users a flexibility in one certain area that. The debate is about whether or not, realistically, they can benefit significantly from that choice, or if its better to standardize.

Don't bring up your anti-religion complaints without warrant, please. No one's impressed that you're yet another person with a grudge against religion.

Last edited by B-Con (2008-06-28 23:00:16)

ibendiben · 2008-06-28 23:22:39

B-Con wrote:

This has nothing to do with any sort of absolute right/wrong or any evolution. It's about offering users a flexibility in one certain area that. The debate is about whether or not, realistically, they can benefit significantly from that choice, or if its better to standardize.
Don't bring up your anti-religion complaints without warrant, please. No one's impressed that you're yet another person with a grudge against religion.

Didn't mean to impress, I'm not even anti-religious. It was just an example case where people choose to standardize. No real conclusion, but you can learn from it.
back on topic:
I think experimentation with new filesystems, like gobolinux for example, is good. That is all I wanted to point out, really. Therefor the idea, by itself appeals to me.

ibendiben · 2008-06-28 23:26:01

Forget it, I shouldn't post such things, I agree.
My mind got carried away, excuses.

pedepy · 2008-06-29 01:07:39

what the fuck. anyway:

I think you're misunderstanding when you're saying 'most users would choose the same hierarchy', because that's not where the problem lies.

Although there *are* standards as to where everything should go, most distros seem to go with what they feel is best, and as such an RPM or a pacman tarball or what not as to be 'packaged' with a particular distro in mind, otherwise things will install to the wrong directories and create a total mess. If say, pacman, were to itself know what goes in '/opt' and what goes in /usr/bin and what goes in /lib and /usr/lib etc. - then packages wouldn't need to include that info, and could be made compatible with a number of different distros, hence simplifying the process of creating packages & distributing software in the first place.

Think of it that way: you make an app, you package it with that system along with source code and/or binary and you just make that available for download on your web page. Anyone running any distro running that package management system would be able to install this, regardless of how this particular distro decided to organize it's FS.

Of course, that distro would have to be *made* to use that package management system, and not the other way around.

Again, those are just my two cents... I'm just lookin for input from ppl who'd know more about the nuts & bolts of why that's possible/impossible/too hard/too stupid an idea.

B-Con · 2008-06-29 02:34:51

I suppose it would help. But you can already compile a package to use whatever heirarchy you want. Instead of making that decision dynamically via pacman, you could just make the decision at compile time. The only thing you would benefit this way would be being able to use packages cross-system (at least on system's with pacman installed), because one compiled package would work for multiple systems rather than just one.

Advantageous, yes, but would be nicer if all package management systems did it that way, rather than just pacman. Obviously we can't make that happen, the devs for the other PMSs would have to make that decision for their own, but that's where the real flexibility would lie. Because even if you want to use the package on more than one system, you'd still need to have pacman installed.

Allan · 2008-06-29 02:56:55

And yet another example of why mentioning religion on forums only leads to trouble. Moving on....

The decision about where files are located needs to be made at compile time for many packages. When you ./configure a package, you tell it where to look for the configuration files etc. So, you can just put the files in different places and hope it will still work. This rules out being able to use this in pacman so the one package can be used across different filesystem layouts. That just would not work.

The other option is to allows these variables to be set so that you can use it in makepkg. I.e. you could go "./configure --sysconfdir=${confdir}". That would allow the PKGBUILDs to be transferable across different filesystem setups. I think that if you are porting Arch's packages to a different filesystem layout, altering the PKGBUILD in this resect will be the least of your problems. I recall that there was a post about this on the pacman-dev list recently and the same conclusion was reached.

So in conclusion, I say this is an interesting idea that is not very useful in practice.

pedepy · 2008-07-02 17:41:26

well i never assumed it would mean less work, just less work for the 'common dev', taking the burden of packaging and distribution software away from them and into the hands of the distro devs.

or is that how it's already being done ?

anyway ..

Arch Linux

#1 2008-06-28 18:21:59

Filesystem abstraction in package management

#2 2008-06-28 18:53:53

Re: Filesystem abstraction in package management

#3 2008-06-28 19:06:16

Re: Filesystem abstraction in package management

#4 2008-06-28 22:47:43

Re: Filesystem abstraction in package management

#5 2008-06-28 22:50:10

Re: Filesystem abstraction in package management

#6 2008-06-28 22:59:27

Re: Filesystem abstraction in package management

#7 2008-06-28 23:22:39

Re: Filesystem abstraction in package management

#8 2008-06-28 23:26:01

Re: Filesystem abstraction in package management

#9 2008-06-29 01:07:39

Re: Filesystem abstraction in package management

#10 2008-06-29 02:34:51

Re: Filesystem abstraction in package management

#11 2008-06-29 02:56:55

Re: Filesystem abstraction in package management

#12 2008-07-02 17:41:26

Re: Filesystem abstraction in package management

Board footer