David R. Morrison wrote:
1) Installing an old version of fink's passwd package under 10.3 will wipeAFAIK 0.5.3 ships with the latest passwd, which does not anymore wipe the existing users, right? That's IMHO the most important part of the picture.
the users on your system. We have to be absolutely certain that users
have an updated passwd package in their tree under 10.3.
Second vital part is that we get out a 0.6.0 release for 10.3 close to the time 10.3 goes public.
Users who just install 10.3 over 10.2 (assuming that would be possible) are not likely to reinstall passwd; they will run into problems due to this, but unless explicitly told, most of them won't type a funky command like "fink reinstall passwd". So, that leaves people trying to install an older release of Fink (e.g. 0.5.2); we can't do anything about this besides putting big WARNINGs on our homepage...
I don't think that putting a check for an up-to-date passwd package into fink itself is any good. Because anybody who gets that new fink is likely to have the new passwd, too. OTOH anybody who has the old passwd probably won't have the new fink anyway.
So, all I see we can do to prevent this problem is to
a) Inform people on how to upgrade to 10.3. Maybe we already now put up a simple page, on which we just tell people that the page will contain update infos once 10.3 is up to date; and to tell them that if they absolutely have to use Fink with a 10.3 prerelease, they should use at the very least fink 0.5.3 (and maybe let's actually explain way; e.g. Perl, passwd)
b) Try to get a 0.6.0 release out of the door in time for 10.3 GM. Of course that depends on enough of us being able to work on this (i.e. having 10.3 seeds and enough time).
If you look beyond that problem: maybe we can even finally ditch passwd in favor of a new better way to handle creation of new users (BTW can somebody tell me how/if DarwinPorts handles this? Maybe a possibility to share some resources). Namely right now, there are some issues when users already exists; also whenever a package needs to create a new user, first passwd has to be updated.
We discussed this before, but nothing ever was done :-/. Idea would be to create a replacement system, which allows packages to "register" a username; when that happens, Fink (or some auxiliary tools invoked by Fink) creates that user account if it doesn't exist yet. Of course that way the custom users would never be removed. We could improve the system by recording which packages requested that user to be added, and remove it when all those packages have been removed. But this causes some pitfalls, and might be a bad idea: e.g. what if a package (incorrectly, of course) forgets to declare that it needs that user. Or what if the user (the human using the computer I mean :-) started to use those user accounts for other things (like maybe he manually installed some games into /usr/local with user "games"). So, is there anything bad about not deleting the users we create?
I don't think it would be hard to create such a system. Only potential problem is that this way, we can't gurantee UIDs (actually, our hardcoding of UIDs of course already is nasty; if a user with the same PID already exists... not nice). I am not sure right now if dpkg encodes user names, or UIDs... anybody know for sure? (otherwise I'll RTFS :-)
Cheers,
Max
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
