Alexander Vlasov wrote: >> I tend to agree with Danek here. Rather than duplicate information >> about the /usr directory in thousands of packages, it makes sense that >> it would be defined by one base package that is guaranteed to be >> installed. >> > Excellent. Please name this package, check if all base directories are > really there and let's write this decision somewhere. It would be really > nice.
Do note that we're not talking about *one* package. One package would deliver /usr. A different package entirely would deliver /opt/sfw/lib/firefox/plugins. Each directory should be delivered by the package that "owns" that directory, that is responsible (in some sense) for defining and managing its contents. Most likely this will be the package that delivers the infrastructure that uses the directory - some core system-y package for /usr, versus an add-on package for something like the Firefox plugins directory. Hmm. Suppose that you have a package that delivers an application that includes a Firefox plugin. Assume that the application is usable without the interaction with Firefox; that's an extra for people who have Firefox. How should this application be packaged in order to support systems with and without Firefox? In the traditional Solaris model, the application's package would probably deliver the Firefox directories, and if Firefox wasn't installed the plug-in would sit there harmless but dead. If we adopt a strict dependency model for directories, the situation gets trickier, since we don't want to have the application require that you install Firefox. Any thoughts? Before somebody says "the packaging subsystem should just automatically create the directories", what ownership and modes should it use and how will this interact with later installing Firefox? _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
