I would humbly suggest your expectations sound unrealistic. The major problems were mostly design issues at heart. The design has not been changed. No matter how long you polish the driftwood, no matter how shiny you get the frequently touched parts, it's still always going to be driftwood, and will never transmute to ivory.

I tried to outline what was needed and where I found some of the info in my post here: http://www.linuxquestions.org/questi...ml#post5108904

(It was kind of a rushed stream of consciousness thing but hopefully it conveys the overall process, I can try to clean it up and walk through it again to see if it makes sens to even me several months on. Maybe Ser Olmy or V Batts might be able to clarify some things better than I could as that was my first time really delving into it :O )

1 members found this post helpful.

PAM is fairly much all-or-nothing as if added, it becomes a hard dependency for programs unless the PAM argument is turned off at compile-time. Some programs have this, and some do not.

The best argument I could give to find out how many packages would require PAMification, would be to thoroughly read through BLFS as a kind of guidebook, and see which packages they have that utilize PAM, that way you have an idea of what requires PAM if added, maybe in Slackware.

There is another option I'm surprised NOBODY failed to mention/ask about.

/extra

Just as AlienBOB has his multilib directory, though it's not in Slackware officially, any and all packages that require PAM could effectively be given a /extra/pam-packages directory either on disk or on the Slackware FTPs, and just maintained that way either with packages or ready-to-use SlackBuild scripts.

1 members found this post helpful.

This has been discussed, though a bit under the radar on IRC. AlienBob suggested exactly this, an extra repo similar to his multilib repo. Only problem is you'd have to find someone to maintain it.

This will be a bit off-topic, but there's more to it than that. The absence of PAM is only one factor in my migration, but there are some others where Slackware is not necessarily at fault. A significant part of my job is teaching, and the last three requests I had from businesses were all specific for Ubuntu Server, which seems to be extremely popular, at least here in France. So I try to meet the client's expectations, and I'm an eat-your-own-dog-food type of admin/teacher. Besides that, there's an unexpected problem using Slackware in France for teaching, it's that most of the folks in France are really bad at understanding even the most basic english. During the last class I taught, there were some vocal protests why we weren't using a translated version of Linux. An entirely different factor, and this is completely unexpected, I've discovered Elementary OS' Pantheon desktop, which is nothing less than the perfect Linux desktop environment I've always been looking for. Right now it's only available for *buntu, Arch and Gentoo, but maybe one day someone will port it to Slackware. Last but not least, I find myself more busy and with less time on my hands these last months, so it's in effect much easier and less time-consuming to setup half a dozen of PPA's on Elementary in order to have a full-fledged workstation with applications galore. For the time being, I had to put my MLED project to sleep, and I don't know when I can pick it up again.

That being said, Slackware will always have a warm place in my heart.

Niki

2 members found this post helpful.

Thanks for sharing. I am in a similar predicament, as you already know from other threads.

Could the defaults be configured to be as transparent as possible, almost to the point that those who do not need PAM would almost not notice?

Is the idea that all of the /extra packages would be direct drop-in replacements? Just use upgradepkg?

The idea is yes, they would be drop-in replacements... such as:

OpenSSH-x-x86_64-1.txz would be replaced with OpenSSH-x-x86_64-1-pam.txz

This way, PAM is not just optional on the system as a whole, but so are the packages, their configuration scripts, etc.

That would mean more maintenance. I'm not sure that the Slackware crew can afford that.

Just a minor nitpick but that suggested name does not follow Slackware package naming conventions. Issuing "echo [full package name] | rev | cut -f4- -d- | rev" should result in the short package name (without the version number, architecture, build tag and extension). Your suggested naming breaks this.

More likely it would be openssh-pam-version-architecture-buildtag.txz (I also lower cased OpenSSH, since this is how the package is named in the official Slackware packages).

If I had a vote (which obviously I don't), I would suggest Slackware adopts PAM. After several years maturation it has obviously got to the stage where it is workable (given pretty much every major distro has a adopted it). Additionally I think it makes life far more difficult not having it, for those that need it in production environments.

P.S. Four years back volkerdi had already hinted at the possibility of Slackware with PAM one day.

I wonder if we are any closer now or not?

and then we re-write all packaging tools to respect the new namings and deal with them.

--
sometimes it have the feeling that some opinions are more based on fundamentalism than on facts.

1 members found this post helpful.

The idea would work assuming there was someone to maintain them. He just got the naming wrong but that part is fixable.

Doesn't have to be in extra though, any interested party with enough time on their hands could do this.

+1.

I am guessing Pat and the team have many script wrappers to automate Slackware maintenance, so perhaps not that much additional maintenance. I suspect the biggest hurdle is introducing PAM into Current so Current users can start kicking tires and revving engines.

Yeah, but we all got the point. Perhaps just replace "SBo" with "PAM" to make the drop-in packages.

Perhaps SBo for 14.2 and after that trial run pull into 15.0?

Yeah, +1 here too. Not saying PAM is a Good Thing or the Right Stuff, but as Pat shared four years ago, the infamous PAM = SCAM days are long gone. I have no personal need for PAM, but adding PAM is one less item to use against Slackware when people choose a distro. Sometimes swimming against the tide forces uncomfortable decisions and adding PAM probably is a reasonable decision nowadays.

For educational purposes, why is PAM bad (I'm not trolling, I'm just curious)?