Hello.
On 10/03/2014 16:26, Nikola M. wrote:
First statement is unfortunately true. To make /dev => /hipster update
possible we need
1) to republish packages which were not rebuilt since /dev a8 with
higher numbers (2014.x)
2) republish incorporations so that they either are empty or depend on
actual packages
I still do not understand this one. Why killing incorporations is so
important,
it seems that incorporations definitions could be updated to reflect
version changes and then go through the testing to make sure everything
under updated incorporation works together.
1) I haven't said about killing incorporations here. I said making them
empty OR dependent on actual packages.
2) But I honestly don't think that incorporations are necessary in
Hipster, perhaps, except entire. They were aimed to control version
numbers of software from different consolidations. But we want to have
only one consolidation . If you want to stick to one package version
just do pkg fix entire after Hipster install. We could avoid publishing
empty entire after ISO release and so make Hipster behave more like
/dev. But I'm inclined to publish empty entire to encourage wider testing.
3) publish neccessary obsoletion / renaming packages
This also needs to be checked and documented, both for recommendations
what to use instead if some package is removed, how to move current
configuration to a new one etc.
Packages can not just be removed with no documentation about what to use
instead in next release.
I don't think so. We have a lot of outdated desktop-related software. It
has sometimes strange dependencies, brings in more outdated software and
so on. I think that it's good trend to remove something old, unused and
unmaintained. If someone wants it back, just fix the package to build in
oi-userland and work on Hipster.
(And there should be releases and not only package updates)
We are publishing snapshots once per several months.
From that basic documentation, later before publishing new /dev
release, documentation for change could be made wider before release,
telling people what to do administering it.
Agree, documentation can be enhanced.
4) test that at least typical text / GUI install can be updated from
latest /dev to /hipster.
Noone volunteered to do it yet.
It was possible before and updating from a8 was almost smooth. And I
think I reported the moment I figured it is not possible.
Response was not to fix it but to ignore it.
It is not possible now. At least until all our packages has greater
versions then /dev. /dev now uses X-0.151.1.9 versions. We have a lot
of X-0.151.1.8 versions. IPS can't handle this. Also, a lot of
obsoletion packages were removed during migration from /hipster to
/hipster-2014.1 repository. Part of them should be republished to allow
/dev => /hipster update.
Hipster with it's always changing contents of packages and no revisions
to jump between different states (versions, like entire etc)
makes quality control and testing almost impossible (figuring out WHEN
and after what change what problem arise)
We have shipped entire with last ISO snapshot. We are going to ship one
more with new ISO snapshot. However, I agree, there's issue with testing
- you can't update/downgrade to the state of some particular date. But
it's true also for other OSes and distributions. Do you propose to
update entire on each package update?
Hipster proved as not suitable for any use but testing and using on
one's laptop or separate test server.
I successfully use it for my labs. Using something illumos-based on our
servers is impossible due to hardware issues. But I don't think I would
persuade my collegues to migrate from Debian to something else even if
illumos supported our hardware :)
Problem with Hipster is that it is not meant to be productiion quality
from the ground up and all philosophy of "let's update a package and see
will someone compain and report a bug"
works quite well for internal releases/strictly "in between" working
updates before next /dev release.
Yes, it was created to speed up OI development. I think it partly
achieved this goal.
Hipster spent too much time going away from Openindiana /dev and it has
to stop doing so.
It's easy to go away from someone standing ;) Seriously, I think that
moving away from legacy consolidations and build systems is a necessary
task to ease OI development and to lower barrier for new devs.
--
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department
_______________________________________________
openindiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
