[bugs] [OpenIndiana Distribution - Bug #1118] /dev-il illumos version will break illumos onu

[illumos bugs]

Issue #1118 has been updated by Andrzej Szeszo.


Rich Lowe wrote:
> Andrzej Szeszo wrote:
> > Not having branch version number would make life easier for people building their own packages. Especially when using pkgdepend to resolve dependencies. Software would not need to re-republished with every release of the distribution. It is possible that in many cases the resulting packages will install fine even on Solaris 11!
>
> That's an artifact of the incorporations, nothing to do with package versioning.  If you want that to be true, alter how you generate the incorporation packages to incorporate less specifically where appropriate.

Let's say I compile mbuffer on oi148 and use pkgdepend to generate dependencies when packaging it. The package will not install on oi151 because it depends on pkg:/system/library/math at 0.5.11-0.148 and pkg:/system/library at 0.5.11-0.148. The issue has nothing to do with incorporations. It is more about how pkgdepend works. If pkgdepend had an option to drop branch version numbers when generating/resolving the dependencies the issue could be worked around by using it.

>
> >
> > Also, people working on a distribution could choose to not to rebuild/republish every single package when preparing new release. Existing packages could be used instead.
> >
>
> That's also the result of incorporations, not versioning.

Not exactly. Illumos packages built on oi148 will not install 100% on oi151 and vice versa (let's say we keep 0.148 branch version). pkgdepend is being used during the packaging phase. So, for example ipfilter package will depend on pkg:/runtime/perl-584 at 5.8.4-0.148 when built on oi148 but it will depend on pkg:/runtime/perl-510 at 5.10.0-0.151 when built on oi151. Some other packages will have branch versioned dependencies (@X.X-0.148 or @X.X-0.151) on expat, glib2, libxml2, libxslt, openssl, zlib and possibly few others which are not part of illumos. You could not really take packages generated on one release and use them on a new one with the current state of things.


>
> > Making incorporations less restrictive is another area to explore. We could make them to be just empty stubs in the development branch of the distribution. We could potentially also remove reverse dependencies on the incorporations from the actual packages. It would make it easier for people to create their own 'backports' of never software without messing with incorporation packages.
>
> That's the right way to achieve all this, though there are packages that _do_ have to be precisely in sync, so just removing them is a bad way to do it.  That also makes it difficult to discover bugs.

In case of "stable" releases keeping stuff in sync would not be an issue if we had separate repos for them and were pushing only security updates/bugfixes to the repos.

In case of the development branch we could ask people to run pkg image-update before reporting any bugs. This is assuming that all pushes to the dev repo are synchonized and latest packages are always in sync. 

> 
> > Again, I am not sure this is the way to go forward and I am probably forgetting about something. Idea itself though makes a lot of sense to me at the moment.
> 
> Certainly not something we can use to fix the immediate problem.

Reverting the number back to 0.148 will not solve the problem completely either due to branch versioned dependencies on external libraries. I am assuming you would like to be able to exchange locally built repos with other people who are not necessarily running the same system as you do. For local onu use adding ONNV_BUILDNUM=151; export ONNV_BUILDNUM to the env file seems to be good enough workaround.
----------------------------------------
Bug #1118: /dev-il illumos version will break illumos onu
https://www.illumos.org/issues/1118

Author: Rich Lowe
Status: New
Priority: High
Assignee: 
Category: OS/Net (Kernel and Userland)
Target version: oi_151_stable
Difficulty: Medium
Tags: 


In the /dev-il repo the build version of illumos was incremented to 0.151, to match everything else.   Because in the illumos source tree the packages remain at 0.148, this means that any packages built from our source tree will no longer install on OI.  It'd be nice to avoid that.

The problem is that if you keep our current version number, people running oi_148 will get the upgrade, because the incorporations aren't (and perhaps can't be) tight enough to prevent it.

Solutions I can think of are:

# Leave illumos version at 0.148, trust that we have done nothing incompatible, and that we'll bump that number if we do
# Have illumos bump their version to match yours, and continue to do so (I'm against this)
# Have illumos bump their version _far_ past you, and give you your own space to play in, as long as you never catch back up and screw it again (ie, call illumos 1.0, and leave you guys with 0.* in which to play).  This is probably the smoothest solution, but I'm sure people will argue about the merits of calling something "1.0", even in a place nobody really looks.




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://www.illumos.org/my/account