On Mon, Mar 17, 2008 at 12:29:53AM -0700, Jyri Virkki wrote: > Danek Duvall wrote: > > > > On Thu, Mar 13, 2008 at 07:56:11PM +0000, Amanda waite wrote: > > > We felt that it's very likely that users will want to run more than one > > > version of Lighttpd on the same system and so provisioned for it. > > > > Why did you think that would be common? Like I said, it doesn't appear > > that this is common on a handful of common Linux distributions; what would > > make the situation different on Solaris? > > Let's see how different is it... In debian today I see for example: > - php4 packages and php5 packages > - apache and apache2 packages
And I understand why those are that way. But I'm not asking about why it's done in general (like you said, this isn't the apache case), but about this particular case. Does lighthttpd need to be treated the same way? Is there a rich community of end-user plugins for lighttpd the way there is for php and apache? Is there binary incompatibility between releases that will cause end-user plugins to break when we upgrade? Are there other things that would go wrong? I'm not saying there isn't, but I don't know -- I'm not terribly familiar with lighttpd. But I strongly get the sense that some teams are versioning the installations because they don't actually want to do the work to find out whether a) there actually are incompatibilities between the releases they might conceivably ship, b) those incompatibilities are relevant to customers and not something the distro can smooth over the transition, and c) customers really will want more than one version at a time, rather than making a jump. Perhaps that analysis actually has been done, but I don't see any evidence of it. > They do it presumably for the same reasons several of the OpenSolaris > project teams have felt the need, which is to provide stability within a > given major release family while at the same time making the > newer-generation apps available. I'd like to take the "presumably" out of that. If there's a real need for the versioning, let's hear it. If there isn't, let's not do it. > > Yup. I don't agree with the way Apache has been versioned, either, though > > I understand why we delivered both 1.3 and 2.x for a while. Why we haven't > > yet gotten rid of 1.3, or why we now ship two versions of 2.x is completely > > beyond me. I think it's nuts. > > There's only one apache22. apache1 is best thought of as a different > product just sharing the same first name, still with its user base. I get that. But I do have SUNWapch2u and SUNWapch22u on my build 83 system (the first delivering 2.2.3, the second 2.2.6). Perhaps the appropriate pkghistory files haven't been delivered, so the older copy isn't being removed? > Anyway, this is not the apache case. I only brought it up because I didn't think a good decision had been made there. Though the binary compatibility argument makes sense to me, as long as there are enough customers for each version range with isolated compatibility to make them worth supporting. That doesn't mean I don't still think it's nuts that people are still using 1.3 how many years after 2.x came out? > Some of the OpenSolaris components have finer-grained versioning than in > Linux, because the Solaris lifecycle and stability expectations are > different. Uncommitted still means stable until the next minor release, > which is a very long time. Unfortunately, the release taxonomy is being shredded at the moment. We used to be able to say that until the in-development release (Nevada at the moment) actually shipped, you could do pretty much anything you wanted, including making incompatible change, and you were only locked in at release. But no one's really sure what that means when you throw SXDE or Indiana into the mix. Danek
