Re: uucp
From: Andre Guibert de Bruet (andy_at_siliconlandmark.com)
Date: 02/11/04
- Previous message: Johan Pettersson: "Re: Bad interrupt routing causes my SATA controller to fail."
- In reply to: Oleg V. Naumann: "Re: uucp"
- Next in thread: Oleg V. Naumann: "Re: uucp"
- Reply: Oleg V. Naumann: "Re: uucp"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 11 Feb 2004 04:12:01 -0500 (EST) To: "Oleg V. Naumann" <oleg@reis.zp.ua>
On Wed, 11 Feb 2004, Oleg V. Naumann wrote:
> On Tue, Feb 10, 2004 at 07:51:48PM -0800, Kris Kennaway wrote:
> > On Tue, Feb 10, 2004 at 07:39:38PM -0800, Randy Bush wrote:
> > > i know uucp went somewhere strange in -current, but i can not
> > > find it in the source tree or in ports. and if i search for
> > > it, i get no useful results (though 'uucp' gets me many hits
> > > none of which contain 'uucp').
> >
> > /usr/ports/net/freebsd-uucp
>
> Yes, this is in the ports tree for CURRENT now. But can anybody
> explain me, why shell for the 'uucp' user in CURRENT still points
> to the '/usr/libexec/uucp/uucico' instead
> '/usr/local/libexec/uucp/uucico', where uucico lives now?
This could only reflect on the number of people that actively use UUCP
with FreeBSD CURRENT in the year 2004.
> >From my point of view there is three things, why this is bogus:
> 1. After upgrade from STABLE shell will be points to the wrong binary
> 2. This is real pain all these cries from mergemaster about differences
> in the master.passwd
You're going to be prompted to merge your /etc/passwd file nonetheless.
We've dropped the 'xten' user since STABLE, for example.
> 3. In the clean CURRENT shell for the uucp user points with finger
> to the sky.
On a clean (w/o uucp) CURRENT install, how is that any different than
pointing to a non-existant /usr/local/libexec/uucp/uucico because the port
isn't installed?
> But why we doesn't have wrapper for the uucico like /usr/bin/perl for
> perl? Looks like this will be much better solution instead fixing shell
> for the uucp user.
A correct fix would be to change the default shell for the user under
CURRENT. One could argue that an even more correct fix would be to remove
the user altogether and have the port create the user on the install make
target with the right login shell. This would entail changing the owner of
the /dev/cua* category of serial character devices, but it's certainly
doable.
Regards,
Andy
> Andre Guibert de Bruet | Enterprise Software Consultant >
> Silicon Landmark, LLC. | http://siliconlandmark.com/ >
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
- Previous message: Johan Pettersson: "Re: Bad interrupt routing causes my SATA controller to fail."
- In reply to: Oleg V. Naumann: "Re: uucp"
- Next in thread: Oleg V. Naumann: "Re: uucp"
- Reply: Oleg V. Naumann: "Re: uucp"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
