On Tue, Apr 8, 2008 at 9:16 AM, Danek Duvall <[EMAIL PROTECTED]> wrote:
> 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:
> > > > 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?
The "release" package would not be the entire OS, it would be the bare
minimum stating what the OS is. FWIW, "rpm -q redhat-release" is very
handy for programatically understanding what OS a server is running.
Parsing /etc/release is much harder.
I started down the path of advocating using the feature namespace for
this in the past, but then deleted the paragraph when I realized that
there was a problem. If there is
pkg://org.opensolaris/feature/mta/sendmail-compatible that I want to
install, the installer doesn't know which sendmail compatible MTA to
install. Perhaps this speaks for the need of an "alternative" (to
borrow the name from Debian) namespace. That is the following
packages would exist:
pkg://org.opensolaris/sendmail
- delivers software
pkg://org.opensolaris/postfix
- delivers software
pkg://org.opensolaris/mtamanager
- delivers software (invented for the sake of conversation)
pkg://org.opensolaris/mutt
- delivers software
- requires
pkg://org.opensolaris/alternatives/mail/mta/sendmail-compatible
pkg://org.opensolaris/evolution
- delivers software
- requires
pkg://org.opensolaris/alternatives/mail/mta/sendmail-compatible
pkg://org.opensolaris/feature/mail/mta/sendmail
- delivers feature
- requires all of:
pkg://org.opensolaris/sendmail
pkg://org.opensolaris/mtamanager
pkg://org.opensolaris/feature/mail/mta/postfix
- delivers feature
- requires all of:
pkg://org.opensolaris/postfix
pkg://org.opensolaris/mtamanager
pkg://org.opensolaris/alternatives/mail/mta/sendmail-compatible
- requires one of:
pkg://org.opensolaris/feature/mail/mta/sendmail
pkg://org.opensolaris/feature/mail/mta/postfix
This would mean that features would be packages that can be specified
at times where automatic dependency mapping will work. Alternatives
provide a means for ensuring features exist but leave it up to an
administrative decision. Unresolved dependencies as a result of a
depening on alternatives would trigger one of the following:
- For an interactive installation, appropriate screen(s) should be
displayed giving the user choice of the various options. There
should be some hint as to which is the preferred option.
- For an automated installation, this should be triggered as an error
during the profile check (equivalent of today's ./check script).
Presumably the automated installation setup could be using the same
front end as used by the interactive installer...
Assuming that there is some sort of method for tagging something as
the preferred alternative, this would mean a button saying "take all
defaults" would be present.
> > 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.
Exactly... this is how it works today if you uninstall sendmail and
manage that on your own.
> > 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.
We're getting off track here...
I fail to see how third parties can deliver sendmail (and samba)
without having to require a specific kernel patch but Sun has such
tight dependencies. Is Sun's sendmail really using private API's that
aren't stable? I can understand once in a while when big things like
sendfile(3ext) is added and it gives a big performance boost. But
this should just be a case of the new sendmail requiring at least
version x of the kernel. The competition doesn't require a reboot to
patch sendmail.
> 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.
For security patches that would otherwise not require a reboot, I
think this is an important option. Of course, I would prefer that
such dependencies are minimized.
This just spawned another pain point, that may be addressed by tags
and attributes. Currently patches are tagged as security, single
user, requires reboot, etc. The problem is that if rev -01 is tagged
as security so is rev -02 even if -02 was only a cosmetic change.
Presumably, patching will be replaced by updating the package. If the
foo-1.0 delivers 100 files and foo-1.1 delivers 100 files by the same
name, there is a pretty good chance that the delta between them is a
small subset of the 100 files.
To deal with this, perhaps the following tags would be useful:
pkg.change.security
Contains the version number of this package the last time this
file was updated due to a security fix
pkg.change.last
Contains the version number of this package the last time this
file was updated.
pkg.change.reboot
Contains the version number of this package the last time this
file required a reboot
pkg.change.singleuser
Contains the version number of this package the last time this
file required single user (or alternate root) installation
This would give an efficient means for tools to determine if updating
the system will be disruptive and to assess the relative importance of
the fix. Additionally, it would provide a way to determine which
files need to be updated without having to worry about hash
collisions. Of those I list above, pkg.change.last is the one I have
the hardest time justifying mainly because I don't know how this works
right now.
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
