[CFT] packaging the base system with pkg(8)

[Edward Tomasz Napierała]

On 0421T2348, Dan Partelly wrote:
> Yes, you are right it misses the media change handler  in devd.conf. 
> maybe it should bementioned somewhere in a man page if it is not
> already there. Thanks for the pointer.

It's mentioned in a comment in auto_master file.  But yeah, mentioning
it in a manual page seems like a good idea.

> Anyway, if I would have written the system, what I would have done
> is to consolidate both user mode daemons into one and make this
> daemon a client of devd, fstyp a library, and handle all removable 
> media inside transparent to the user, without requiring any modifications
>  to devd.conf, and without relaying on shell scripts. 
> 
> Is there any reason you did not took this approach ? This is not
> criticism, I am genuinely interested.

Yes - I actually like shell scripts.  I like being able to provide
the glue in a way that's easy to debug and modify, without having
to rebuild anything, so that it can be tailored to specific needs
by the system administrator.

In this case the problem, I think, is not with the shell scripting.
It's just that it doesn't "enable itself" when needed, or isn't
just enabled by default.

> >  and simply
> > retrofit the changes back to autofs - but that hasn't happened (yet).
> 
> Please consider doing it.  A kevent on /media would allow other programs
> to see how volumes come and go, and I can imagine several situations 
> where this can be handy. And too many directories left there do become
> annoying. 

Well, you have devd notifications for this - and it gives you much more
flexibility.

> > On 21 Apr 2016, at 23:20, Edward Tomasz Napierała <trasz at FreeBSD.org> wrote:
> > 
> > On 0421T1526, Dan Partelly wrote:
> >> The scenario is:
> >> 
> >> Let’s say I have autofs_enable , working with media map.
> >> 
> >> If I have a CD in CD drive , all is well and when the system is fully booted up
> >> /media contains a directory through which I can access the content of the 
> >> CD-ROM. Now if you eject this CD , and insert a new one, nothing happens.
> >> /media does not contain a new access point for the new disk inserted in the 
> >> device.  
> >> 
> >> What I would expect is when I change the media in Cd-rom , a new 
> >> access point for the volume in question should be reated in /media.
> >> 
> >> Perhaps this functionality is exposed differently by the automounter,
> >> but them I would not expect the CDrom to be accessible at all though the 
> >> media map. 
> > 
> > If by "access point" you mean the directory, then it will, unless the CD
> > doesn't have a label - in that case the device name will be used instead,
> > and since it's the same device, it will be the same name - usually "cd0".
> > 
> > However - I've just checked to make sure and it works the way it should.
> > What you're decribing seems like you're missing the part of devd.conf(5)
> > responsible for notifying autofs about media change.  Do you?
> > 
> >>> he problem here is that it's quite hard to fix, there's a risk
> >>> of breaking existing functionality, and the problem is largely cosmetic.
> >> 
> >> until you have more than 10 of them there, when it largely annoying.
> >> anyway, what is the reason it is very hard to fix and it would break existing
> >> functionality. can you please shed some light ?  
> > 
> > Basically, the autofs doesn't support removing the nodes.  It wasn't
> > really required for the usual use case, and it simplified the code a lot.
> > Plan was to pick it up again with my next filesystem project, and simply
> > retrofit the changes back to autofs - but that hasn't happened (yet).
> > 
> > [..]
>