> E: Unable to locate package libdhash-dev > E: Unable to locate package libcollection-dev > E: Unable to locate package libini-config-dev
Like I said, "libcollection, libdhash, libini-config, their -dev's" are
needed.
> More work for whoever ends up maintaining it. This is about as far as
> I'm willing to take this exercise. The only thing I'm likely to do
> about sssd now is to seek removal if this bug isn't fixed.
These libs used to be part of sssd, up to at least 1.2.1, so I am not sure if
they need individual packaging. Anyway, the current maintainer has already
started maintaining said packages in Debian.
However, I admit having them as separate packages is cleaner, but probably not
worth it in the wheezy timescale.
Would packaging all of these into one sssd package be acceptable for wheezy?
> 1.8.1 will need to be supported eventually, there is no point doing the
> work for 1.6.2 in a way that prevents 1.8.1 ever being possible. To do
> so would be very short sighted.
I only mentioned that detail because that is what I happen to be running now.
Of course, the current LTM version is the right way to go for packaging this
un Debian.
> TBH I think sssd users are going to have to get used to not having sssd
> available in Debian and will need to migrate to something else. There
I would be willing to take sssd if I had any experience in maintaining a
Debian package (apart from some built for internal purposes). Therefore, I
concur: the 84 users (according to popcon) who are using sssd at the moment
will need to migrate to something else.
However, I do not think there IS something else. At least I am not aware of
ANY alternative to sssd. Are you? The closest thing I know of is libpam-
ccreds, but that does not provide nss, just the equivalent of libpam-sss.
> Debian. This bug has already been open for 8 months without anyone
> actually providing a workable solution, likely due to a lack of
> interest in sssd in the long term.
Perhaps the Ubuntu people would be of help here? They already package this and
the only thing preventing me from using those packages directly is the fact
that they depend on upstart. (I have not tested upstart, perhaps it is vastly
superior to sysv-rc, but *depending* on it seems like a bad idea: I cannot
believe a daemon really depends on upstart and would not work with sysv-rc.)
> If nobody cares enough to do the work, sssd will have to be removed.
Agreed. I would hate to go to upstart (sysv-rc is not broken, so I would
rather NOT replace it with anything), but unless I can get someone to help me
get started with maintaining this and others, sssd will need to go. Where
should I ask for mentor/sponsor?
> Please drop me from CC now, I've done what I can. The rest is down to
> those who have a reason to work on sssd. I don't.
I still sent you this despite the request, I hope you are not offended. As the
questions I ask are of a generic nature, I thought you might be able to answer
them despite declaring otherwise. =)
Cheers,
Juha
--
-----------------------------------------------
| Juha Jäykkä, ju...@iki.fi |
| http://www.maths.leeds.ac.uk/~juhaj |
-----------------------------------------------
signature.asc
Description: This is a digitally signed message part.
