On Tue, Apr 08, 2008 at 08:15:35AM -0500, Mike Gerdts wrote: > On Mon, Apr 7, 2008 at 11:18 PM, Danek Duvall <[EMAIL PROTECTED]> wrote: > > On Mon, Apr 07, 2008 at 10:43:54PM -0500, Mike Gerdts wrote: > > > Part of the smarts of pkg(1M) and similar utilities could be to know that > > > packages with an FMRI starting with pkg://org.opensolaris/ for SunOS 5.11 > > > sparc should be found out http://pkg.opensolaris.org/SunOS/5.11/sparc. > > > > Repositories are going to be one-OS only. Depending on what you really > > mean by "5.11", either it's part of the version string (the built-on > > component) or it's the version of the "Solaris" incorporation, and "sparc" > > is merely a tag on files in the packages. > > Again, this will likely prove to be problematic when you start to see > mirrors of repositories pop up.
That's only problematic for hosting more than one authority at a single URL, which wasn't one of the things I addressed. > > > Since you don't necessarily know what architecture or OS build is > > > being used in an image that is being installed, > > > > We will know what architecture it is -- it has to be part of the image > > creation, or we won't know what files to get from each package. > > True - you will know what it was, but uname(1) may not tell you. For > example, in a snap upgrade situation, you may be installing SunOS 5.12 > on a system that says it is SunOS 5.11. Branded zones may make it so > that you are installing SunOS 5.11 on a SunOS 5.14 system. Yes, but the architecture of the system -- the thing I addressed -- can't change without a reinstall (at least, it's not worthwhile, I don't think). > > > it may make sense to encourage each package to have a dependency on > > > a particular "release" package > > > > Why not depend on the package(s) that actually provide the interfaces > > you depend on? > > The same interface may be provided by different packages. For > example, postfix and sendmail both provide an executable called > /usr/lib/sendmail and speak SMTP on port 25. For those people that > aren't doing a lot of uucp mail relaying and like a human readable > (and writable) configuration, postfix is a very attractive software > package. It strikes me that depending on the entire OS just to pull in SMTP server capability is a bit broad of a net. Wouldn't this be an appropriate place to use your "feature" category? > Sun also has a history of making it so that sendmail and the kernel > are patched in the same patch. Presumably if this was a requirement > in the past, in the future updated versions of the sendmail and the > kernel will have co-dependencies in their updated packages. Optional co-dependencies -- thus if you don't have sendmail installed on your system, you won't get it dragged on to your system just because it crossed a kernel flag-day. Bart's wad currently out for review is the beginnings of that. > For this reason, there is additional incentive for system administrators > to remove the Sun sendmail package in favor of sendmail or postfix from > anyone else. If Sun's sendmail is used, you may have to schedule a > reboot (may take weeks) to get a critical security fix for sendmail. Well, if sendmail happens to depend on something provided by the kernel that's also changed, then the kernel has to get upgraded, too. Not doing so means you're off the reservation. It may be that postfix avoids crossing that flag-day, but maybe it doesn't. If it's critical enough, it might just be worth building sendmail on a system prior to the flag-day. It would create another support branch, but would release people from the flag-day. The branch could be a) more expensive and b) short lived, so that people are forced to cross the flag-day and join everyone else, but give them sufficient time to arrange for that. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
