Salix Forums

Do not use slackpkg clean-system in any case. In fact, do not use slackpkg at all. slackpkg is designed to manage a single slackware repository and nothing but that.

thenktor wrote: Such a feature is totally not KISS for me and IMHO it's pure nonsense. Why would I care about some unneeded packages that are installed? They only need few MB on my many GB hard disc.

Well.... there are netbooks sold quitte recently with 2GB SSDs, not to mention legacy systems. On those removing cruft is actually important. In general I don't want all sorts of nonsense on my system even if it has a lot of storage. So... I disagree. I think this is an important feature, one that can be implemented. VectorLinux, a Slackware derivative which uses slapt-get/gslapt has done it successfully so SalixOS can as well.

gapan wrote:In fact, do not use slackpkg at all. slackpkg is designed to manage a single slackware repository and nothing but that.

That is a very important point. This is a problem that occurs when using an upstream repository instead of mirroring the SlackWare repository and removing things which aren't compatible. SalixOS is probably 99.9% Slackware compatible, but it isn't 100%. The net result is that there are a few things in the repository which either don't work or are actually dangerous. slackpkg falls into the dangerous category.

Shador wrote:Such a feature would make us significantly different from Slackware and as I don't think it's something the Slackware user base could want

A lot of the Slackware user base is opposed to any sort of automated dependency checking. One the reasons I run SalixOS and not vanilla Slackware is that I do want dependencies handled similarly to any other modern distribution that isn't Slackware. There are reasons why there are so many Slackware derivatives (reliability, stability, performance) and there is also a reason why almost all of them have dependency checking implemented. The lack of it is, to many people including myself, a major shortcoming in vanilla Slackware. Having dependency management automated is a huge time saver.

JRD wrote:In Salix/Slackware, I don't think it's possible, as there is no difference between a package choosen to be installed by the user and a package installed by dependancy.

I don't think that distinction has to be made to detect orphans. You may want to check with either JAOS (developer of slapt-get/gslapt) or the VectorLinux people. I know it is possible but I haven't looked into the mechanics of how it's done.

caitlyn wrote:That is a very important point. This is a problem that occurs when using an upstream repository instead of mirroring the SlackWare repository and removing things which aren't compatible. SalixOS is probably 99.9% Slackware compatible, but it isn't 100%. The net result is that there are a few things in the repository which either don't work or are actually dangerous. slackpkg falls into the dangerous category.

But this isn't us breaking compatibility with Slackware, it's slackpkg fault as Slackware is designed for and around multiple repositories!

caitlyn wrote:A lot of the Slackware user base is opposed to any sort of automated dependency checking. One the reasons I run SalixOS and not vanilla Slackware is that I do want dependencies handled similarly to any other modern distribution that isn't Slackware. There are reasons why there are so many Slackware derivatives (reliability, stability, performance) and there is also a reason why almost all of them have dependency checking implemented. The lack of it is, to many people including myself, a major shortcoming in vanilla Slackware. Having dependency management automated is a huge time saver.

Still such a feature is not KISS and therefore opposed to our philosophy. Adding dependencies the way it's done now is perfectly OK for me, because it's optional (--no-deps) and because there is an acceptable relation between complexity added, effort needed and gained benefit.
Personally, I look upon dependencies as a help. Slackware doesn't add it because they think it's bloat, but we provide that aid as it is useful and simple to deploy. An aid also implies non-complete automation, errors are possible and though desirable to fix, the user is responsible in the end.
Adding orphans support leads to complete automation and that's not KISS. Therefor it gets into one's way. If you want to do it properly, have a look at Debian. They distinguish between automatically and manually installed packages in a local database. But this system has so many drawbacks.
Amongst which is the fact that aptitude/apt-get are significantly slower than slapt-get.
Furthermore this database becomes easily "corrupted" (e.g. packages are installed by a package tool not maintaining that database, dependencies are installed manually).

Complexity adds errors which leads to displeasure and it takes control away. That's exactly what KISS tries to prevent.

PS: If somebody invents a great way to work around this problems, I wouldn't oppose to such a feature. The point is I see no such way, so I don't want to waste my time with it.

Shador wrote: But this isn't us breaking compatibility with Slackware, it's slackpkg fault as Slackware is designed for and around multiple repositories!

It is most definitely the fault of any distribution that includes packages that cause breakage in their repository. Poorly written or inappropriate code does not remove the fact that a Linux distributor is ultimately responsible for what is in their distro repositories.

Shador wrote:Still such a feature is not KISS and therefore opposed to our philosophy

When you say "our" who do you mean? Are you a SalixOS developer? Do you set policy for SalixOS? IMHO, a lot of FOSS projects get way too caught up in philosophical issues and forget that an OS is a tool. It's always about functionality, not philosophy. When philosophical purity becomes paramount everything else, including functionality, suffer.

Shador wrote:An aid also implies non-complete automation, errors are possible and though desirable to fix, the user is responsible in the end.

Fixing bugs is ALWAYS the responsibility of the developer and distributor, not the end user. I say that as a developer, BTW.

Shador wrote:Adding orphans support leads to complete automation and that's not KISS.

Philosophical dribble. That is not a reason to add or not add anything at all.

Shador wrote:Therefor it gets into one's way.

How so? How does better automation get in my way? I'd really like to know.

Debian is not a model for how to do dependencies. Red Hat does a better job, IMNSHO, but I wouldn't want to see SalixOS move to rpm packaging either. Slackware apt (apt-get/gslapt) is perfectly fine and, as I already noted, can already handle orphaned package checking. Your whole argument about the problems in Debian and the performance of aptitude (apt-get is deprecated now) is irrelevant. It's really a red herring.

Shador wrote:Complexity adds errors which leads to displeasure and it takes control away. That's exactly what KISS tries to prevent.

More generic philosophical dribble. Stop spouting philosophy and explain how this particular, already extant feature is problematic. How is dependency checking in VectorLinux more complex or problematic than SalixOS? I know they user slack-required files generated by requiredbuilder rather than .dep files generated by depfinder, but that, to me is a non-issue.

Shador wrote:PS: If somebody invents a great way to work around this problems, I wouldn't oppose to such a feature.

I think that has already been done. Once again, it would be worth exploring with JAOS and with vector7.

I wanted to write something but Shador's post covered me. Well, except that he probably meant to write:

But this isn't us breaking compatibility with Slackware, it's slackpkg fault as Slackware is not designed for and around multiple repositories!

Shador and I also have already demonstrated how this can be done in an automated fashion earlier in this thread and how error prone that is, so I won't go back to that again.

caitlyn wrote:Well.... there are netbooks sold quitte recently with 2GB SSDs, not to mention legacy systems. On those removing cruft is actually important. In general I don't want all sorts of nonsense on my system even if it has a lot of storage. So... I disagree.

You're free to disagree, but even in that case, we're offering the "basic" mode installation which installs only a minimum set of packages with xfce. And then a user with such a small hard drive can select to install any small applications fit his needs on top of that and there will be no additional, unneeded packages installed. No need to start from a full system and try to strip that down. We even have a wiki page on how to remove unneeded xorg video drivers.

caitlyn wrote:VectorLinux, a Slackware derivative which uses slapt-get/gslapt has done it successfully so SalixOS can as well.

I haven't tried vector lately. I might do just to check that out, but I'm quite sure it has all the disadvantages I'm thinking about. And I'm constantly in contact with Jason, the developer of slapt-get/gslapt and I know for a fact that he doesn't want his software to have any of that "orphan" functionality.

caitlyn wrote:It is most definitely the fault of any distribution that includes packages that cause breakage in their repository. Poorly written or inappropriate code does not remove the fact that a Linux distributor is ultimately responsible for what is in their distro repositories.

We don't include slackpkg in salix. It is available from slackware repositories, but that's it. And I don't think it's poorly written or anything. It does what it's designed to do well, it's just isn't designed to manage multiple repositories, which we absolutely need in salix.

caitlyn wrote:When you say "our" who do you mean? Are you a SalixOS developer? Do you set policy for SalixOS?

His userbar is what it is for a reason.

caitlyn wrote:Fixing bugs is ALWAYS the responsibility of the developer and distributor, not the end user. I say that as a developer, BTW.

Agreed. That's one of the reasons we're not going to implement anything like it. It's so error prone that it will be full of bugs that nobody has the time to handle.

caitlyn wrote:apt-get is deprecated now

I wasn't expecting to find you misinformed about that.

Actually ubuntu just decided to remove aptitude from their default installation and stick with apt-get only.

caitlyn wrote:Fixing bugs is ALWAYS the responsibility of the developer and distributor, not the end user. I say that as a developer, BTW.

Yes, it is. My point was that software can be designed to require user intervention. It wasn't so wise to call those situations errors/bugs though as you're completely write real bugs should be fixed by the developers.
Still theoretically you could design a software to be buggy and then that would be right. Honeypots could be a use case.

caitlyn wrote:How so? How does better automation get in my way? I'd really like to know.

As I already mentioned it steals your control and already because of that it gets into my way as I need/want that control. Additionally automation is error-prone so it's getting even more into my way.
From a developers point of view too much automation gets into my way because it's quite time-consuming and under the prerequisite that it's too much (i.e. unnecessary) I waste my time with it, which I could have spent developing more needed functionality or with real life.

caitlyn wrote:It's always about functionality, not philosophy.

What about this one: "It's all about target group orientation."
We as the developers also consider us ourselves the target group of Salix and among the rest of that group we vote for strict KISS (e.g. because we want control about our systems) and in our eyes the feature you request is not what our target group wants.

gapan wrote:I wanted to write something but Shador's post covered me. Well, except that he probably meant to write:
But this isn't us breaking compatibility with Slackware, it's slackpkg fault as Slackware is not designed for and around multiple repositories!

I concluded from the fact that there extra and patches that it was, but maybe I misunderstood that. Anyway, that's not the point.

Shador wrote:I concluded from the fact that there extra and patches that it was, but maybe I misunderstood that. Anyway, that's not the point.

Those hardly count as separate repositories. They are just different directories of the same repository.

gapan wrote:We don't include slackpkg in salix. It is available from slackware repositories, but that's it.

Not meaning to split hairs, but... isn't the entire Slackware repository mirrored by SalixOS? Isn't the Slackware repository required by SalixOS? If so what's in their repository is in SalixOS. It's not installed by default, of course, but it's still included and there is nothing other than this forum thread to warn off a user from installing it.

gapan wrote:And I don't think it's poorly written or anything. It does what it's designed to do well, it's just isn't designed to manage multiple repositories, which we absolutely need in salix.

Understood. I wasn't claiming it was poorly written, BTW. I was making a general statement about distributor responsibility. I probably wasn't clear enough in what I wrote.

gapan wrote:His userbar is what it is for a reason.

I see that now. OK, that part of my post was stupid.

gapan wrote:That's one of the reasons we're not going to implement anything like it. It's so error prone that it will be full of bugs that nobody has the time to handle.

This seems to be the crux of the disagreement. I've seen it work well enough and I don't believe it is necessarily error prone.[/quote]

caitlyn wrote:apt-get is deprecated now

gapan wrote:I wasn't expecting to find you misinformed about that.
Actually ubuntu just decided to remove aptitude from their default installation and stick with apt-get only.

I didn't know that. I've basically given up on Ubuntu. Talk about a bug filled mess!

Yeah, I guess I'd better make this part clear: I don't want SalixOS to be like Ubuntu, now or ever. I don't even want it to be like Debian. I want it to have all the reliability, performance and stability of Slackware with some time saving features. In other words, I like it pretty well the way it is

Thank you for letting me know that Jason didn't design that functionality into slapt-get. Interesting, because if you try and remove one of the rebuilt GSB packages in Vector it rips out all the packages that depend on it too. There are way too many interlinking dependencies in that. vector7 (Robert Lange) and Rodrigo Bistolfi admitted that including GSB in VL 6.0 was a mistake. I'm quite sure they won't do that again.

Anyway, the problems and errors that occur, in my experience, with dependency management and orphan handling can almost always be put down to poor packaging or not building in a clean environment. That results in lots of extra unneeded and interlinking dependencies. That's essentially what you've already seen with the gvfs-1.0.3 package as discussed here: http://www.salixos.org/forum/viewtopic.php?f=15&t=911. It was undoubtedly built on a machine with KDE installed and somehow a bunch of KDE became unnecessary dependencies. It isn't the added functionality that's buggy or even necessarily complex. It actually can and should be really simple if the packagers and repository maintainers do their jobs properly.

I need to check in with the VL developers again. It's been quite some time. I'll try and catch Robert & co. on IRC tonight. Y'all have gotten me really curious about what they have and haven't done. I really thought they were using vanilla slapt-get/gslapt. Now you've got me wondering if that's true or not and if some code was added or hacked in slapt-get.

caitlyn wrote:Thank you for letting me know that Jason didn't design that functionality into slapt-get. Interesting, because if you try and remove one of the rebuilt GSB packages in Vector it rips out all the packages that depend on it too.

Afaik that feature is already there, but that's not orphan handling. Try this:

Code: Select all

slapt-get -i wammu
slapt-get -remove gammu

Should install and remove both gammu and wammu (if you're on current you need slapt-get -u first as I just fixed a md5 error which somehow crept in)

Salix Forums

Orphans

Re: Orphans

Re: Orphans

Re: Orphans

Re: Orphans

Re: Orphans

Re: Orphans

Re: Orphans

Re: Orphans

Re: Orphans

Re: Orphans