swaret will die soon, gware freerock is gone!!

zborgerd · 02-09-2007, 01:02 PM

Quote:

Originally Posted by Ilgar

I don't use a package management tool either, and I'm happy this way. I would be upset though if both Freerock and Gware projects die. I know that most people say Dropline is the best; however it would be nice to have a less intrusive alternative (shadow -> PAM business etc.).

Btw, Gware page says they're testing 2.16.1 for 11.0. Apparently things are going slowly due to lack of time, but it's safe to say that Gware is not quite dead yet.

Odds are that any future version of Slackware with HAL support will require PAM (it's explicitly becoming a HAL requirement for policykit), so it may be a non-issue pretty soon.

At least, if that were to happen, we might finally hear the end of the complaints about it.

Quite frankly, I can't see how anyone would want a modern Linux distribution without at least basic PAM support... But hey. To each his own, I guess.

Ilgar · 02-10-2007, 12:22 AM

Yeah I wonder about the same thing, too. I tried to compile HAL recently, and PAM was needed for policykit. I abandoned it at that point. A new 2.6-only Slack without HAL doesn't make much sense so it's reasonable to have PAM in the next Slack. Maybe it's one of the things that made Pat's silence so long -- apparently there are very big changes coming up.

danieldk · 02-10-2007, 04:59 AM

Quote:

Originally Posted by Ilgar

Yeah I wonder about the same thing, too. I tried to compile HAL recently, and PAM was needed for policykit. I abandoned it at that point. A new 2.6-only Slack without HAL doesn't make much sense so it's reasonable to have PAM in the next Slack. Maybe it's one of the things that made Pat's silence so long -- apparently there are very big changes coming up.

Or write a patch that makes HAL work without policykit, or policykit without PAM

.

Ilgar · 02-10-2007, 05:52 AM

Well obviously Pat can't do that himself

. He once said Slack is not a home for orphaned software. If he doesn't include HAL and the like (which have pretty much become standard) he will contradict that statement. At some point the move must be made to the new generation software. Although I like my Slack box and I'm happy the way 11.0 is prepared, I would be disappointed if the first 2.6 based Slack did not include new stuff like HAL.

danieldk · 02-10-2007, 07:39 AM

Quote:

Originally Posted by Ilgar

Well obviously Pat can't do that himself

. He once said Slack is not a home for orphaned software. If he doesn't include HAL and the like (which have pretty much become standard) he will contradict that statement. At some point the move must be made to the new generation software. Although I like my Slack box and I'm happy the way 11.0 is prepared, I would be disappointed if the first 2.6 based Slack did not include new stuff like HAL.

Heh, how is not including something making Slackware a home for orphaned software?

Anyway, word goes that HAL will be included in the future, but that could just be a rumor.

BTW. to the PAM naysayers: there's a different PAM implementation than Linux-PAM, OpenPAM. OpenPAM is used in NetBSD and FreeBSD:

http://trac.des.no/openpam

danieldk · 02-10-2007, 07:43 AM

BTW, from the OpenPAM readme:

Code:

OpenPAM is an open source PAM library that focuses on simplicity,
correctness, and cleanliness.

OpenPAM aims to gather the best features of Solaris PAM, XSSO and
Linux-PAM, plus some innovations of its own.  In areas where these
implementations disagree, OpenPAM tries to remain compatible with
Solaris, at the expense of XSSO conformance and Linux-PAM
compatibility.

These are some of OpenPAM's features:

   - Implements the complete PAM API as described in the original PAM
     paper and in OSF-RFC 86.0; this corresponds to the full XSSO API
     except for mappings and secondary authentication.  Also
     implements some extensions found in Solaris 9.

   - Extends the API with several useful and time-saving functions.

   - Performs strict checking of return values from service modules.

   - Reads configuration from /etc/pam.d/, /etc/pam.conf,
     /usr/local/etc/pam.d/ and /usr/local/etc/pam.conf, in that order;
     this will be made configurable in a future release.

Seems like a natural fit

.

zborgerd · 02-10-2007, 11:48 AM

Quote:

Originally Posted by danieldk

BTW, from the OpenPAM readme:

Code:

OpenPAM is an open source PAM library that focuses on simplicity,
correctness, and cleanliness.

OpenPAM aims to gather the best features of Solaris PAM, XSSO and
Linux-PAM, plus some innovations of its own.  In areas where these
implementations disagree, OpenPAM tries to remain compatible with
Solaris, at the expense of XSSO conformance and Linux-PAM
compatibility.

These are some of OpenPAM's features:

   - Implements the complete PAM API as described in the original PAM
     paper and in OSF-RFC 86.0; this corresponds to the full XSSO API
     except for mappings and secondary authentication.  Also
     implements some extensions found in Solaris 9.

   - Extends the API with several useful and time-saving functions.

   - Performs strict checking of return values from service modules.

   - Reads configuration from /etc/pam.d/, /etc/pam.conf,
     /usr/local/etc/pam.d/ and /usr/local/etc/pam.conf, in that order;
     this will be made configurable in a future release.

Seems like a natural fit

.

Not really. Every PAM application on Linux is pretty much designed with Linux-PAM in mind. I don't personally see any benefit to using OpenPAM right now. OpenPAM is not as mature as Linux-PAM, and is probably more trouble than it is worth as Linux-PAM is fairly well-proven. Every Linux distribution out there (to my knowledge) uses Linux-PAM. For Slackware to use something else (even though it wouldn't surprise me) would be a step in the wrong direction. Not to mention, OpenPAM is really intended to be a solution for BSD, rather than Linux (even though it's supposed to function on most POSIX-like systems), and development is extraordinarily slow compared to Linux-PAM.

Though, at this point, I don't think I'd care which one he'd use, as long as it worked with policy-kit and we could plug pam_redhat into it as well.

Alien_Hominid · 02-10-2007, 12:36 PM

Slow coding doesn't mean that the package is poorly coded. Knowing the security priority in *bsd systems, slow coding isn't very exceptional case.

danieldk · 02-10-2007, 03:10 PM

Quote:

Originally Posted by zborgerd

Every PAM application on Linux is pretty much designed with Linux-PAM in mind.

PAM is more or less standardized. Yes, not everyone sticks to that standard, but most of the applications that can use PAM on Linux also work with PAM on (Free/Net)BSD.

Quote:

Not to mention, OpenPAM is really intended to be a solution for BSD, rather than Linux (even though it's supposed to function on most POSIX-like systems),

Good, portable, software is supposed to run on most UNIX-like systems.

Quote:

and development is extraordinarily slow compared to Linux-PAM.

I can't judge about Linux-PAM, but I think a focus on code quality and security is more important than features or whatever.

Ilgar · 02-10-2007, 03:54 PM

Quote:

Originally Posted by danieldk

Heh, how is not including something making Slackware a home for orphaned software?

Well, if you don't upgrade to the current standards you'll soon find yourself using archaic software. Archaic is not the same as orphaned

, yes, but the former soon becomes the other in general. At least in the case of PAM the initial security and stability concerns (the two reasons of using some old software in Slack) seem to be sorted out. If Slack doesn't upgrade when it can, it will look like Pat thinks using old stuff is a virtue.

angryfirelord · 02-10-2007, 04:31 PM

Quote:

Originally Posted by rkrishna

H_TeXMeX_H
earlier i had enough time so i try manage to make package of my own, "make and checkinstall" now it is difficult, busy with my works. i didnt even checked lq forum for months!!

angryfirelord,
will try slapt-get, later!!, what this gslapt exactly does? seems like a gui from gnome for slaptget!!

nutronix, me too, it will keep the machine uptodate with official packages..

GSlapt is a gui for slapt-get, very similar to synaptic for apt-get, but it's not gnome or gtk dependent. It just makes it a little easier to get & search for pkgs and add repos. I don't know if the slapt-get/gslapt combo solves dependencies, but it's better than using straight slackpkg tools, which requires you to manually search and download the packages.

Haven't tried Swaret, so I can't make a comparison.

adriv · 02-10-2007, 04:50 PM

I've been using Kslackcheck for almost a year now. It doesn't install anything (which I like very much), just downloads the packages and places them in a folder in your /home/ which you can easily update with upgradepkg. It also has the possibility to blacklist (like kernel-stuff, Alsa and so on) packages and choose a mirror nearby.

I know it is a KDE-thing, but I guess you can get it working in Gnome...