GNU introduces Guix, a distro independent package manager based on Nix
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
but this thread is not about that anyway if you read from the beginning. It is however asking about peoples thoughts on an alternative packaging and software installation scheme and dependency resolution is simply a side effect of it's proposed utilisation.
This thread is about a new dependency resolving package manager and it is posted in the Slackware forum. The lack of dependency resolution is one of the main advantages of Slackware for many Slackers, so of course dependency resolution will be a part of the discussion. The hardest part to implement for a resolving package management system is proper resolution of dependencies, especially when you implement rollback features, so it is not at all only a side effect that this package manager can resolve dependencies, it is purely intentional.
Quote:
I still after all the years I have been using Slackware fail to understand why those using it are so afraid of embracing new ideas.
Neither package management nor dependency resolution are new ideas at all. So here is another package management system. Now what?
Distribution: Slackware 14 (Server),OpenSuse 13.2 (Laptop & Desktop),, OpenSuse 13.2 on the wifes lappy
Posts: 781
Rep:
Quote:
Originally Posted by TobiSGD
This thread is about a new dependency resolving package manager and it is posted in the Slackware forum.
As I said, it brings out the worst in the fan boyz. maybe you should go and read the website about it. You will see it's not just about dependency resolution, but about a new way of dealing with software installation that just happens to incorporate it.
Here's a quote from it.
Quote:
An important consequence is that operations like upgrading or uninstalling an application cannot break other applications, since these operations never “destructively” update or delete files that are used by other packages.
You can't say that about building from source which very often breaks things.
Quote:
Originally Posted by TobiSGD
The lack of dependency resolution is one of the main advantages of Slackware for many Slackers, so of course dependency resolution will be a part of the discussion. The hardest part to implement for a resolving package management system is proper resolution of dependencies, especially when you implement rollback features, so it is not at all only a side effect that this package manager can resolve dependencies, it is purely intentional.
Neither package management nor dependency resolution are new ideas at all. So here is another package management system. Now what?
Looking at what the developers are trying to achieve your right, it is another packaging system. The difference seems to be that they hope to eliminate the problems associated with other package management schemes, whether simplistic like Slackware, or complex like Debian et al.
No one is suggesting that even if it were successful in its apparent aims that one needs to use it.
So again I ask, what is everyone so afraid of? It's more or less a proof of concept at the moment anyway and as I said in an earlier post, an interesting project to watch.
I can't see problems with the Slackware package management system that need to be fixed. Would be nice if you give some examples.
Also, I never had problems with building from source breaking anything. Some example would be nice here, too.
if one wanted to experiment something new, they should do like Chrome OS: whenever a new system upgrade or critical update is available, the OS will load it in the background, user will be alerted that an update is available and prompted to reboot to take effect.
This could be a feature for paying users.
no, thanks.
absolutely nothing personal, but I had enough of that kind of sh1t with a notorious OS from Redmond
no, thanks.
absolutely nothing personal, but I had enough of that kind of sh1t with a notorious OS from Redmond
Then you should have changed the update settings, I always tell my Windows install to just notify me if updates are available. No automatic downloads, no automatic installs.
I would prefer to hear from people who have experienced Guix, if any, than YABDADM (*)...
As a side note it is not surprising that Guile Scheme be used for extensions in a GNU project. As we see here :
Quote:
If a GNU program wants to be extensible, it should use GUILE as the programming language for extensibility—that is the GNU standard extensibility package. For some programs there's a reason to do things differently, but please use GUILE if that is feasible.
(*) Yet Another Boring Discussion About Dependencies Management
Last edited by Didier Spaier; 11-26-2012 at 02:05 PM.
vdemuth:
Whoa boy, what's with the personal attack.
It wasn't intended to be. It's just a trend I've seen in your past posts, that you continue to display on this thread as well.
Quote:
I read what was put by kikinovak and see his point.
Your previous statement says otherwise:
Quote:
Your point being?
Quote:
But, and bear with me here, lets take his situation. Yes the packaging team at CentOS may not have robustly checked if the quality of the Gnome package but I find it unlikely that for someone who has been using CentOS for 5 years would have allowed it to be a showstopper and even though it may have taken a year for the packagers to fix it, does that mean he was without his OS for 12 months?
I never said he was without his OS for 12 months. I said the mistakes of others ended up hindering the end user rather than helping them. Not to forget that certain package managers will overwrite fixes by the system administrator by itself without the system administrator even knowing about it in worse scenarios.
Quote:
If you look at it from a different angle for a minute, how long do you think it would be after issuing a command to install a package set (say Gnome) that you would be informed by the package manager that not all dependencies were met. Now compare that time with how long it could potentially have been had you needed to install the whole lot from source to find issues. Even Pat wont do that with Gnome, which speaks volumes. So which scenario gave him information sooner rather than later, and allowed him to work on a solution rather more quickly?
If you look at older Slackware versions (I don't know how long you've been using Slackware), GNOME was a part of Slackware, so Pat once did do that with GNOME, so there's very little depth to that volume you speak of.
As for your example scenario, the dependency resolving package manager gave him the information quicker, but if the package maintainers screwed it up again, then it's hampering the end user even longer.
Quote:
You know, I have read a lot of threads about dependency resolution and whether it should be included in Slackware or not and it always brings out the worst in the fan boyz, but this thread is not about that anyway if you read from the beginning. It is however asking about peoples thoughts on an alternative packaging and software installation scheme and dependency resolution is simply a side effect of it's proposed utilisation.
Fanboys or not, Slackware chose not to resolve dependencies and that's in the documentation since the very early 90's. You're acting like that's a surprise for some reason.
Quote:
I still after all the years I have been using Slackware fail to understand why those using it are so afraid of embracing new ideas.
Ask yourself, why are distributions with dependency resolving package managers so afraid to give up the dependency resolution? Even though time and time again, it becomes clear the package managers have made (and continue to make) mistakes, why don't they just give it up?
I want just to note that GUIX use something like Apple's MacOS/X software bundles for packages, then its philosophy is at huge distance of orthodox Slackware and even an typical Linux distribution like RedHat, Ubuntu or OpenSuSE...
To understand what I want to say, if you have installed VirtualBox or QtCreator, look how these apps are installed in your /opt... That is what is called an software bundle.
Yeah, GUIX support dependency resolution, rollbacks and all the Santa's bells, BUT it is the GNU package manager, not an sine-die Linux package manager. And GNU is not equal with Linux Operating System, even we use the GNU user level tools. The GNU Operating System is called glorious HURD.
And, I personally, I do not care if GNU want an appleish package manager for its Hurd & Co., even I'm an supporter of introducing of dependency support* in Slackware.
* Read dependency support as in registration of them to make the life easy for an 3thy party dependency resolution app, not as in introducing RPM as default package manager.
Last edited by Darth Vader; 11-26-2012 at 05:13 PM.
As a side note it is not surprising that Guile Scheme be used for extensions in a GNU project. As we see here : If a GNU program wants to be extensible, it should use GUILE as the programming language for extensibility—that is the GNU standard extensibility package. For some programs there's a reason to do things differently, but please use GUILE if that is feasible.
But GUILE is almost never feasible. That's the reason, why this Guix thing will never get traction in Linux land. Remember GNU arch?
Distribution: Slackware 14 (Server),OpenSuse 13.2 (Laptop & Desktop),, OpenSuse 13.2 on the wifes lappy
Posts: 781
Rep:
Quote:
Originally Posted by Darth Vader
I want just to note that GUIX use something like Apple's MacOS/X software bundles for packages, then its philosophy is at huge distance of orthodox Slackware and even an typical Linux distribution like RedHat, Ubuntu or OpenSuSE...
To understand what I want to say, if you have installed VirtualBox or QtCreator, look how these apps are installed in your /opt... That is what is called an software bundle.
Yeah, GUIX support dependency resolution, rollbacks and all the Santa's bells, BUT it is the GNU package manager, not an sine-die Linux package manager. And GNU is not equal with Linux Operating System, even we use the GNU user level tools. The GNU Operating System is called glorious HURD.
And, I personally, I do not care if GNU want an appleish package manager for its Hurd & Co., even I'm an supporter of introducing of dependency support* in Slackware.
* Read dependency support as in registration of them to make the life easy for an 3thy party dependency resolution app, not as in introducing RPM as default package manager.
At last, the voice of reason from someone who gets it.
The fact that it is a GNU system means there will conceivably, but not necessarily, be the possibility of inclusion in a GNU/Linux (for that is what all distributions are) distribution at some time in the future. However far ahead that might be.
At last, the voice of reason from someone who gets it.
The fact that it is a GNU system means there will conceivably, but not necessarily, be the possibility of inclusion in a GNU/Linux (for that is what all distributions are) distribution at some time in the future. However far ahead that might be.
but I had enough of that kind of sh1t with a notorious OS from Redmond
The difference is that on the other notorious OS from Mountain View this system works pretty well, plus it's a proper Linux OS, once you switch the Chromebook to developer mode.
At the end of the day the primary job of a package management is to provide the user with sufficient software to have a productive system. I see nothing wrong with making this process transparent to the end user if it achieves the goal.
I am dual booting Chrome OS and Slackware and I have the best of both worlds.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.