Orphans

[gapan]

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.

Sure it is available. But when someone is using any piece of software, they should be expecting to do what that software was designed to do. And slackpkg is designed to handle slackware repositories only. A look in its man page/help files will clearly show that. OK, maybe we can create a page in the FAQ section in our wiki to warn against using it.

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.

Wait. Are we talking about two completely different things here? That functionality is also available in salix of course. Try removing libpng for example with slapt-get or gslapt. It will prompt to take away half of your installed packages with it. But that is not "orphan" handling, not in the way it was talked about in this thread anyway.

[caitlyn]

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

Actually, that is part of orphan handling. I see where you are making the distinction, though. I think the misunderstanding is that I thought you were saying that didn't work in SalixOS when in fact it does. OK, SalixOS has most of what I am looking for.

What you are talking about is the ability to do a single command to remove any orphaned packages as a separate function from doing a slapt-get --remove. That's nice but not strictly necessary.

Wait. Are we talking about two completely different things here?

In part, yes. That may be where some of the disagreement/confusion lies.

There is additional orphan handling functionality in slapt-get when used in combination with --dist-upgrade. Take a look at the --remove-obsolete option, for example. (Yes, I know using dist-upgrade is not recommended and I am not about to try it ) slapt-get can also remove downloaded package files that are no longer available in the repo from the cache with the --autoclean option. That's part of orphan handling as well.

So... it IS implemented in slapt-get/gslapt and therefore SalixOS, just not as completely as some people would like. Now I understand. That's for clarifying it for me, Shador.

[caitlyn]

Sure it is available. But when someone is using any piece of software, they should be expecting to do what that software was designed to do.

You are assuming the user will be knowledgeable about the limitations of the package. You can't make that assumption.

And slackpkg is designed to handle slackware repositories only. A look in its man page/help files will clearly show that. OK, maybe we can create a page in the FAQ section in our wiki to warn against using it.

That's a good idea. In an ideal world it wouldn't be in the repos SalixOS uses at all. Since you rely on upstream repositories rather than one which covers everything in the distro maintained by y'all that isn't possible. It's a relatively minor drawback to the way SalixOS repositories are setup.

Of course, if it bites someone you know where they won't consider it minor.

That functionality is also available in salix of course. Try removing libpng for example with slapt-get or gslapt. It will prompt to take away half of your installed packages with it.

Got that now, thanks!

[thenktor]

But that is not "orphan" handling, not in the way it was talked about in this thread anyway.

This is dependency handling

remove downloaded package files that are no longer available in the repo from the cache with the --autoclean option

Or never have been part of the repository. At least for me this has nothing to do with orphan handling. It's just something to handle unknown packages ("Die, you damn unknown package, die!").

You are assuming the user will be knowledgeable about the limitations of the package. You can't make that assumption.

Changing the package/repo manager is not anything a user not capable to read should do anyway...

EDIT:

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.

Try "other modern" debian based distris and you know what dependency hell means... I hate the way they are splitting every package and adding tons of dependencies then. On such distros you probably really need stuff like orphan handling, but i still don't like the whole attempt to do things there.

[SalmonEater]

quote:
caitlyn Post subject: Re: Orphans PostPosted: 11 Jun 2010, 15:06

"What you are talking about is the ability to do a single command to remove any orphaned packages as a separate function from doing a slapt-get --remove. That's nice but not strictly necessary."
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Yes, this is exactly what autogestion and I were searching for, and what apparently gave rise to this lively interchange. I see it boils down to a philosophical difference (a Debian vs Slackware difference in approach) and involves nuances of the same between even Salix and Slackware itself.
"Verrrrry interesting," as Schultz would say.
It is very informative for a newbie to Slackware and Salix like myself (and I'm almost certain, for autogestion) to be a "fly on the wall" while this has been going on.
Please let us know what those at VL (I didn't like the KDE version of that distro, myself) say re: this.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
". . . 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."
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Yes, indeed!

Thank you, lady and gentlemen!

[Duncan_Idaho]

You are assuming the user will be knowledgeable about the limitations of the package. You can't make that assumption.

If I remember correctly salix was primarily targeted to advanced/knowledgeable users, so I think he is in his right to make that assumption

[Akuna]

You are assuming the user will be knowledgeable about the limitations of the package. You can't make that assumption.

If I remember correctly salix was primarily targeted to advanced/knowledgeable users, so I think he is in his right to make that assumption

OK... this is a bit off subject but since I'm probably the main guy in Salix team sort of rooting for the newbies...

I just wanted to say this: while it is true that Salix OS is not a newbie centric distro but was rather designed for 'lazy slackers', it is still important to realize that as any distros, we will attract our fair share of newbies (not to forget our own granny, neighbors & friends for whom we installed our favorite OS) . Therefore, as much as possible, we need to account for the needs of the inexperienced newcomers (or the very lazy slacker) in our community.

Wiki articles are ideal because they make the information available to those who make the efforts to learn & understand things.

Being a newbie is not bad in itself, I mean aren't we all newbies at something at some point? What is bad is being a whinny 'consumer' who is too lazy to put the food in its own mouth & demands that 'you' do it for him. There is a difference.

[caitlyn]

If I remember correctly salix was primarily targeted to advanced/knowledgeable users, so I think he is in his right to make that assumption

Even knowledgeable users won't know every package in a repository. Someone who knows Slackware but is knew to SalixOS will not know automagically that slackpkg won't work. So, no, you really can't make assumptions about what a given user may know or not know. It's not about general knowledge but about knowing a specific package

[gapan]

There: http://www.salixos.org/wiki/index.php/C ... h_Salix%3F
Fixed now.

[JRD]

What about automatically blacklist slackpkg in slaptget.rc ?