[belenix-discuss] Back to belenix development

[Sriram Narayanan]

Hi folks,

Due to various circumstances, I've managed to make time for belenix work again. I'll keep the lists posted with progress reports.

Sriram

[Cedric Blancher]

Any news?

Ced
--
Cedric Blancher <cedric....@googlemail.com>
Institute Pasteur
_______________________________________________
belenix-discuss mailing list
http://mail.opensolaris.org/mailman/listinfo/belenix-discuss
http://groups.google.com/group/belenix-discuss

[Cedric Blancher]

On 16 August 2012 20:21, Cedric Blancher <cedric....@googlemail.com> wrote:
> On 20 July 2012 20:40, Sriram Narayanan <sri...@belenix.org> wrote:
>> Hi folks,
>>
>> Due to various circumstances, I've managed to make time for belenix work
>> again. I'll keep the lists posted with progress reports.
>
> Any news?

More specific: Has been there any progress on a Illumos ON which uses
SystemV package?

[Joerg Schilling]

Cedric Blancher <cedric....@googlemail.com> wrote:

> On 16 August 2012 20:21, Cedric Blancher <cedric....@googlemail.com> wrote:
> > On 20 July 2012 20:40, Sriram Narayanan <sri...@belenix.org> wrote:
> >> Hi folks,
> >>
> >> Due to various circumstances, I've managed to make time for belenix work
> >> again. I'll keep the lists posted with progress reports.
> >
> > Any news?
>
> More specific: Has been there any progress on a Illumos ON which uses
> SystemV package?

I believe that there is no hope that Illumos will ever do this.

Given the fact that Illumos changed a lot of things that people outside Nexenta
would not like, believe the best way to deal with this problem is to base on
SchilliX-ON that supports SVr4 packages and by cherry picking the good things
from Illumos.

Please note that the act of getting SVr4 packages back is currently "only" 99%
ready and that was two weeks of hard work, because the code base was build 147+
at that time and the last Sun maintained svr4 pkg version was from build 135.
In addition, the state of the SVr4 package description for build 135 was not
sane, as the prototype files contained many files that were neither OSS nor
part of the redistibutable binary packages.

BTW: the current plan is to enhance the "pkgadm" command to give similar
features as the "pkg" IPS command.




Jörg

--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

[Lionel Cons]

On 20 August 2012 12:43, Joerg Schilling

<Joerg.S...@fokus.fraunhofer.de> wrote:
> Cedric Blancher <cedric....@googlemail.com> wrote:
>
>> On 16 August 2012 20:21, Cedric Blancher <cedric....@googlemail.com> wrote:
>> > On 20 July 2012 20:40, Sriram Narayanan <sri...@belenix.org> wrote:
>> >> Hi folks,
>> >>
>> >> Due to various circumstances, I've managed to make time for belenix work
>> >> again. I'll keep the lists posted with progress reports.
>> >
>> > Any news?
>>
>> More specific: Has been there any progress on a Illumos ON which uses
>> SystemV package?
>
> I believe that there is no hope that Illumos will ever do this.
>
> Given the fact that Illumos changed a lot of things that people outside Nexenta
> would not like, believe the best way to deal with this problem is to base on
> SchilliX-ON that supports SVr4 packages and by cherry picking the good things
> from Illumos.

Problems:
- SchilliX uses Bourne shell as /usr/bin/sh, not ksh93. This pretty
much kills the option
- SchilliX is completely out of sync with Illumos and there's no easy
way to find a starting point. We've tried, we failed after investing a
week of work. Most of that was wasted with getting SchillyX to
compile.

Lionel

[Joerg Schilling]

Lionel Cons <lionelc...@googlemail.com> wrote:

> Problems:
> - SchilliX uses Bourne shell as /usr/bin/sh, not ksh93. This pretty
> much kills the option

Could you please stop spreading lies?

Jörg

--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

[Simon Toedt]

On Mon, Aug 20, 2012 at 1:17 PM, Joerg Schilling
<Joerg.S...@fokus.fraunhofer.de> wrote:
> Lionel Cons <lionelc...@googlemail.com> wrote:
>
>> Problems:
>> - SchilliX uses Bourne shell as /usr/bin/sh, not ksh93. This pretty
>> much kills the option
>
> Could you please stop spreading lies?

I'm new to the list, so excuse me if this has been discussed beforehand.

Joerg, could you please explain what the lie here exactly is? I don't get it.

Also, who really wants to go back to the Bourne shell (the old one... not bash)?
Who is going to maintain it? bash and ksh93 have active communities
with many people working on it, while for the Bourne shell I only see
one active person, which is Joerg Schilling.
Who is going to fix all software packages which expect that
/usr/bin/sh is something more posixly? Does this project have the
manpower to adjust every configure, every call to system(), every call
to popen(), every perl/python script with embedded calls to the shell?
Who is going to push the patches to upstream and convinces them to
take them? This sound pretty much like an endless Don Quichotte fight
which just consumes developer time for no purpose and benefit.

Simon

[Joerg Schilling]

Simon Toedt <simon...@gmail.com> wrote:

> On Mon, Aug 20, 2012 at 1:17 PM, Joerg Schilling
> <Joerg.S...@fokus.fraunhofer.de> wrote:
> > Lionel Cons <lionelc...@googlemail.com> wrote:
> >
> >> Problems:
> >> - SchilliX uses Bourne shell as /usr/bin/sh, not ksh93. This pretty
> >> much kills the option
> >
> > Could you please stop spreading lies?
>
> I'm new to the list, so excuse me if this has been discussed beforehand.

First a note: Lionel Cons is well known for frequently posting false claims
to confuse people. This is not the first similar posting from him.

> Joerg, could you please explain what the lie here exactly is? I don't get it.

What dou you like to get explained?

> Also, who really wants to go back to the Bourne shell (the old one... not bash)?
> Who is going to maintain it? bash and ksh93 have active communities
> with many people working on it, while for the Bourne shell I only see
> one active person, which is Joerg Schilling.

Do you really believe this? Then you seem to miss basic information.

> Who is going to fix all software packages which expect that
> /usr/bin/sh is something more posixly? Does this project have the
> manpower to adjust every configure, every call to system(), every call
> to popen(), every perl/python script with embedded calls to the shell?
> Who is going to push the patches to upstream and convinces them to
> take them? This sound pretty much like an endless Don Quichotte fight
> which just consumes developer time for no purpose and benefit.

Didn't you get it? Lionel Cons did send a lie, do you believe that it makes
sense to start a discussion based on a lie?

I am of course happy to discuss things if the discussion is based on facts.
So if you have a real question, you are of course welcome!

Jörg

--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

[Lionel Cons]

On 20 August 2012 13:17, Joerg Schilling

<Joerg.S...@fokus.fraunhofer.de> wrote:
> Lionel Cons <lionelc...@googlemail.com> wrote:
>
>> Problems:
>> - SchilliX uses Bourne shell as /usr/bin/sh, not ksh93. This pretty
>> much kills the option
>
> Could you please stop spreading lies?

*deep breath*
OK, I am trying hard not to be offended.

Joerg, please explain what you mean with "lies".
I'm trying to apply a management view here: What are the advantages
and what are the disadvantages, what are the single point of failures,
how much time must be invested?

As far as I can see ksh93 is the option which consumes less time, has
less disadvantages, no single point of failures (relating to the
problem that you are (AFAIK) the only maintainer for the Solaris
Bourne shell) and is established in Solaris 11. What's wrong with this
picture in a *realistic* world?

Lionel

[Joerg Schilling]

Lionel Cons <lionelc...@googlemail.com> wrote:

> On 20 August 2012 13:17, Joerg Schilling
> <Joerg.S...@fokus.fraunhofer.de> wrote:
> > Lionel Cons <lionelc...@googlemail.com> wrote:
> >
> >> Problems:
> >> - SchilliX uses Bourne shell as /usr/bin/sh, not ksh93. This pretty
> >> much kills the option
> >
> > Could you please stop spreading lies?
>
> *deep breath*
> OK, I am trying hard not to be offended.
>
> Joerg, please explain what you mean with "lies".
> I'm trying to apply a management view here: What are the advantages
> and what are the disadvantages, what are the single point of failures,
> how much time must be invested?

I am not shure whether I get you right..... do you like me to explain you the
management view of your lie?

Please come back to reality and have a fact based discussion.

Jörg

--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

[Lionel Cons]

On 20 August 2012 13:55, Joerg Schilling

<Joerg.S...@fokus.fraunhofer.de> wrote:
> Lionel Cons <lionelc...@googlemail.com> wrote:
>
>> On 20 August 2012 13:17, Joerg Schilling
>> <Joerg.S...@fokus.fraunhofer.de> wrote:
>> > Lionel Cons <lionelc...@googlemail.com> wrote:
>> >
>> >> Problems:
>> >> - SchilliX uses Bourne shell as /usr/bin/sh, not ksh93. This pretty
>> >> much kills the option
>> >
>> > Could you please stop spreading lies?
>>
>> *deep breath*
>> OK, I am trying hard not to be offended.
>>
>> Joerg, please explain what you mean with "lies".
>> I'm trying to apply a management view here: What are the advantages
>> and what are the disadvantages, what are the single point of failures,
>> how much time must be invested?
>
> I am not shure whether I get you right..... do you like me to explain you the
> management view of your lie?

Yes, please. But I also think you should calm down and consider the
*tone* of your next messages. I think we'll find more than one person
who will call for a final ban of your person in this list if you
continue with unprovoked use of offensive language.
I do have over 30 years of management experience in the IT industry,
including CERN and Siemens, and I think I do understand some of the
problems. So far you have not provided a single *solution* to the
problems I listed, or Simon listed. Instead we've only seen defamation
but no facts from your side.

> Please come back to reality and have a fact based discussion.

So what are the facts in your opinion?

Lionel

[Joerg Schilling]

Lionel Cons <lionelc...@googlemail.com> wrote:

> On 20 August 2012 13:55, Joerg Schilling
> <Joerg.S...@fokus.fraunhofer.de> wrote:
> > Lionel Cons <lionelc...@googlemail.com> wrote:
> >
> >> On 20 August 2012 13:17, Joerg Schilling
> >> <Joerg.S...@fokus.fraunhofer.de> wrote:
> >> > Lionel Cons <lionelc...@googlemail.com> wrote:
> >> >
> >> >> Problems:
> >> >> - SchilliX uses Bourne shell as /usr/bin/sh, not ksh93. This pretty
> >> >> much kills the option
> >> >
> >> > Could you please stop spreading lies?
> >>
> >> *deep breath*
> >> OK, I am trying hard not to be offended.
> >>
> >> Joerg, please explain what you mean with "lies".
> >> I'm trying to apply a management view here: What are the advantages
> >> and what are the disadvantages, what are the single point of failures,
> >> how much time must be invested?
> >
> > I am not shure whether I get you right..... do you like me to explain you the
> > management view of your lie?
>
> Yes, please. But I also think you should calm down and consider the
> *tone* of your next messages. I think we'll find more than one person
> who will call for a final ban of your person in this list if you
> continue with unprovoked use of offensive language.

Well, it may be that you don't know that you are sending false claims because
you are uninformed, but then you are still a person that tries to send
repeated offending claims based on wild guesses.

Given the fact that you again started to send attacks against me, it is hard
not to be offended by you.

If you are really in a "leading" position, how many customers did you lose
because of your discussion style?

BTW: This is off topic to this list and unless you return to a fact based
discussion, I like to see an EOD.

Jörg

--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

[Simon Toedt]

On Mon, Aug 20, 2012 at 1:49 PM, Joerg Schilling

<Joerg.S...@fokus.fraunhofer.de> wrote:
> Simon Toedt <simon...@gmail.com> wrote:
>
>> On Mon, Aug 20, 2012 at 1:17 PM, Joerg Schilling
>> <Joerg.S...@fokus.fraunhofer.de> wrote:
>> > Lionel Cons <lionelc...@googlemail.com> wrote:
>> >
>> >> Problems:
>> >> - SchilliX uses Bourne shell as /usr/bin/sh, not ksh93. This pretty
>> >> much kills the option
>> >
>> > Could you please stop spreading lies?
>>
>> I'm new to the list, so excuse me if this has been discussed beforehand.
>
> First a note: Lionel Cons is well known for frequently posting false claims
> to confuse people. This is not the first similar posting from him.

I have serious doubts about that comment. If I look up 'joerg
schilling ksh93' in a search engine I get very wild comments from you
but without substantial claims what the problem is. If I look up
'lionel cons' I get search results about a well respected scientist
(even a project manager!) at CERN. So at least at the first glance
your comments about Mr. Cons do not fit.

>
>> Joerg, could you please explain what the lie here exactly is? I don't get it.
>
> What dou you like to get explained?

I think I asked enough questions in my last mail:
- Who are the other maintainers of the Bourne shell? Please list three
or four persons. bash has at least four, including Chet Ramey, Brian
Fox and lots of other people. ksh93 has at least David G. Korn, Glenn
Fowler, Phong Vo, Jeff Korn and Roland Mainz as recent active
developers. Who's your crew?

- Who is going to fix all software packages which expect that
/usr/bin/sh is something more posixly? Does this project (Belenix, not
SchillyX) have the manpower to adjust every configure, every call to

system(), every call to popen(), every perl/python script with

embedded calls to the shell? This might be a question for the Belenix
project leads to answer.

- Who is going to push the patches to upstream and convinces them to

take them? This sound pretty much like an endless Don Quichotte fight

which just consumes developer time for no purpose and benefit. I have
doubts that some projects will actually accept such patches.

- What are the benefits from reintroducing the Bourne shell as
/usr/bin/sh? It seems everyone else has moved on and uses ksh93 in
Illumos and it's clones/distributions.

>> Also, who really wants to go back to the Bourne shell (the old one... not bash)?
>> Who is going to maintain it? bash and ksh93 have active communities
>> with many people working on it, while for the Bourne shell I only see
>> one active person, which is Joerg Schilling.
>
> Do you really believe this? Then you seem to miss basic information.

What is this basic information? Please educate me.

>
>> Who is going to fix all software packages which expect that
>> /usr/bin/sh is something more posixly? Does this project have the
>> manpower to adjust every configure, every call to system(), every call
>> to popen(), every perl/python script with embedded calls to the shell?
>> Who is going to push the patches to upstream and convinces them to
>> take them? This sound pretty much like an endless Don Quichotte fight
>> which just consumes developer time for no purpose and benefit.
>
> Didn't you get it? Lionel Cons did send a lie, do you believe that it makes
> sense to start a discussion based on a lie?

I have severe doubts in the 'lie' comment as his mail did IMO not
contain enough information to make up a lie. I lack context. What is
this context?

Simon

[Joerg Schilling]

Simon Toedt <simon...@gmail.com> wrote:

> >> Joerg, could you please explain what the lie here exactly is? I don't get it.
> >
> > What dou you like to get explained?
>
> I think I asked enough questions in my last mail:
> - Who are the other maintainers of the Bourne shell? Please list three

[Lots of questions removed because they do not make sense for a fact based discussion]

I kindly asked you to ask questions that are not based on the lies from
Lionel Cons. You unfortunately continue to send questions that only make sense
if you believe what Mr. Cons claimed.

So have you been confused by Mr. Cons?

I recommend you to inform yourself about what's really going on and send more
adequate questions.

Jörg

--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

[Simon Toedt]

On Mon, Aug 20, 2012 at 3:00 PM, Joerg Schilling
<Joerg.S...@fokus.fraunhofer.de> wrote:
> Simon Toedt <simon...@gmail.com> wrote:
>
>> >> Joerg, could you please explain what the lie here exactly is? I don't get it.
>> >
>> > What dou you like to get explained?
>>
>> I think I asked enough questions in my last mail:
>> - Who are the other maintainers of the Bourne shell? Please list three
>
> [Lots of questions removed because they do not make sense for a fact based discussion]

Joerg, would you please ANSWER these questions? They have
significance. At least for me they do so that I can understand the
overall picture.

> I kindly asked you to ask questions that are not based on the lies from
> Lionel Cons. You unfortunately continue to send questions that only make sense
> if you believe what Mr. Cons claimed.
>
> So have you been confused by Mr. Cons?

No, I think not. I'm a educated man. The problem appears to be that
you actively avoid answering questions.

> I recommend you to inform yourself about what's really going on and send more
> adequate questions.

I did inform myself in the last two hours. As far as I can Google
around I have not seen a single, fundamentally based fact from you
about the problem what's wrong with ksh93 or Bourne shell. Most of
your messages about this particular topic are offensive rants where
you scold people being confused, stupid, dumb and calling them idiots
or assholes... but no facts.
Please deliver facts. I can't find them.

Simon

[Joerg Schilling]

Simon Toedt <simon...@gmail.com> wrote:

> > [Lots of questions removed because they do not make sense for a fact based discussion]
>
> Joerg, would you please ANSWER these questions? They have
> significance. At least for me they do so that I can understand the
> overall picture.

I am not willing to start a discussion that is based on imputations.

If you are not able or willing to have a fact based discussion, it seems that I
cannot help you.

I am of course willing to answer questions about the Bourne Shell as well as
questions about ksh93 and/or OpenSolaris - even questions about the relation
about the shells to OpenSolaris and the POSIX standard as long as the
questions are not based on imputations.

BTW: you seem to have close to no relation to OpenSolaris (even less that Mr.
Cons), so why did you enter this thread?

Jörg

--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

[Moinak Ghosh]

Answering the original question since I do not wish to participate
in the other endless debate ...

On Sat, Aug 18, 2012 at 10:24 AM, Cedric Blancher

<cedric....@googlemail.com> wrote:
> On 16 August 2012 20:21, Cedric Blancher <cedric....@googlemail.com> wrote:
>> On 20 July 2012 20:40, Sriram Narayanan <sri...@belenix.org> wrote:
>>> Hi folks,
>>>
>>> Due to various circumstances, I've managed to make time for belenix work
>>> again. I'll keep the lists posted with progress reports.
>>
>> Any news?
>
> More specific: Has been there any progress on a Illumos ON which uses
> SystemV package?
>

Due to various engagements, including another interesting project I
have been working on, I have not yet focused full energy into working
on this. However I am doing some work and one conclusion I have
come to is that I do not want to touch the existing SVR4 codebase.
This comes from past experience with the codebase @ SUN. In one
short word it is horrid. I do not wish to waste my time on that.

This does Not mean not having SVR4 compatibility. I have been
exploring Pacman from Arch Linux:
https://wiki.archlinux.org/index.php/Pacman

It is a very interesting tool, has got all the features and should be
extendable to support the SVR4 spec. After working with RPM5 for
some time I found its complexity and external dependencies to be
high. Pacman only requires libarchive and libcurl.

Supporting SVR4 correctly will require some effort but I think it is
doable getting a cleaner implementation in the process and avoiding
re-inventing wheels.

Regards,
Moinak.
--
================================
http://moinakg.wordpress.com/

[Joerg Schilling]

Moinak Ghosh <moi...@belenix.org> wrote:

>
> Due to various engagements, including another interesting project I
> have been working on, I have not yet focused full energy into working
> on this. However I am doing some work and one conclusion I have
> come to is that I do not want to touch the existing SVR4 codebase.
> This comes from past experience with the codebase @ SUN. In one
> short word it is horrid. I do not wish to waste my time on that.

If you know real problems in the SVr4 pkg format or implementation, feel free
to shre them with others.

> Supporting SVR4 correctly will require some effort but I think it is
> doable getting a cleaner implementation in the process and avoiding
> re-inventing wheels.

The result from my investigations is that it is easier to get the few missing
parts into the SVR4 package that to make the reinvented wheel (IPS) work to my
needs.

Jörg

--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

[Moinak Ghosh]

Forgot to cc list on the replies.

On Tue, Aug 21, 2012 at 7:54 PM, Moinak Ghosh <moi...@belenix.org> wrote:
> On Mon, Aug 20, 2012 at 10:17 PM, Joerg Schilling
> <Joerg.S...@fokus.fraunhofer.de> wrote:
>> Moinak Ghosh <moi...@belenix.org> wrote:
>>
>>>
> [...]

>>> come to is that I do not want to touch the existing SVR4 codebase.
>>> This comes from past experience with the codebase @ SUN. In one
>>> short word it is horrid. I do not wish to waste my time on that.
>>
>> If you know real problems in the SVr4 pkg format or implementation, feel free
>> to shre them with others.
>>
>

> It has been a long time, approx 5yrs since I last touched that code and
> difficult to recollect everything. Some tidbits I do remember:
>
> 1. SVR4 does not have the concept of package upgrade. So if for eg
> pathnames are changed in a new package release old one has to be
> uninstalled and new version reinstalled to do a clean update. However
> it is not possible to do this with core system packages, so it needs
> wrapper scripts or custom class-action scripts. So pathname changes
> in core OS pkgs may also require system config updates. There is no
> support for doing these other than through custom wrapper scripts.
>
> 2. The concept of action scripts is a powerful one but with no control
> it creates a complete mess. For eg every team in SUN that ever provided
> a driver had their slightly different variant of the driver
> install action
> script. It was a mess of action scripts all around.
>
> 3. I remember a team member fixing a customer escalated bug when he
> figured out that a particular supposedly binary search for looking up
> pathnames was actually doing a linear search - some messy code.
>
> This only points to the age of the codebase, 25yrs approx. Old and
> somewhat clunky with a whole bunch of commands and libs.
>
> 4. The approach of keeping all pathnames in a single large text file
> (/var/sadm/install/contents) is suboptimal. While this was updated
> by Casper Dik sometime back there are other such things. Limitations
> had only been patched over and over without any significant cleanups
> or re-writes to fix old design limitations.
>
> SVR4 had excellent concepts, in fact was state of the art 25yrs back.
> The concepts are still awesome even by today's standards but
> implementation leaves much to be desired.
>
> Adding missing pieces to SVR4 will mean first and foremost a repo
> mechanism, package management and seamless upgrade support.
> Once again trying to re-do solved problems. I was forced into the
> unfortunate wheel re-invention for an earlier BeleniX version because
> we did not want to touch IPS with a barge pole and we had no choice
> in the short term but to develop Spkg:
> http://moinakg.wordpress.com/2008/11/22/the-belenix-package-manager/
>
> http://belenix.svn.sourceforge.net/viewvc/belenix/trunk/spec_files/ext-sources/spkg?revision=175&view=markup
> http://belenix.svn.sourceforge.net/viewvc/belenix/trunk/spec_files/ext-sources/spkg_mod.py?revision=395&view=markup
> http://moinakg.wordpress.com/2008/11/22/the-belenix-package-manager/
>
> It had all the useful features and brought in at least one concept that
> "I dare say" was discussed within the IPS team later, without attribution
> of course. However it was never intended to be a full fledged replacement
> before people jump to find flaws in that.
> It took about 6 months part-time effort for a single person to develop
> compared to the 3-years of elaborate intricate complex wheel re-invention
> with the intention to solve world package hunger and even do, surprise
> surprise Windows package installation!

>
>>> Supporting SVR4 correctly will require some effort but I think it is
>>> doable getting a cleaner implementation in the process and avoiding
>>> re-inventing wheels.
>>
>> The result from my investigations is that it is easier to get the few missing
>> parts into the SVR4 package that to make the reinvented wheel (IPS) work to my
>> needs.
>

> I want to give a wide berth to both IPS and the existing SVR4
> "implementation".
> I actually respect SVR4 as a concept but am not interested in doing anything
> with its current codebase.

>
> Regards,
> Moinak.
> --
> ================================
> http://moinakg.wordpress.com/

[Moinak Ghosh]

Please see inline ...

On Tue, Aug 21, 2012 at 8:55 PM, Joerg Schilling

<Joerg.S...@fokus.fraunhofer.de> wrote:
> Moinak Ghosh <moi...@belenix.org> wrote:
>
>> It has been a long time, approx 5yrs since I last touched that code and
>> difficult to recollect everything. Some tidbits I do remember:
>

> Thank you for your reply...

>
>
>> 1. SVR4 does not have the concept of package upgrade. So if for eg
>> pathnames are changed in a new package release old one has to be
>> uninstalled and new version reinstalled to do a clean update. However
>> it is not possible to do this with core system packages, so it needs
>> wrapper scripts or custom class-action scripts. So pathname changes
>> in core OS pkgs may also require system config updates. There is no
>> support for doing these other than through custom wrapper scripts.
>

> The data base has a lot of related concepts and the mportant thing to know is
> that you first need to install the new package and then remove the old one.
> There are reference counters and there is the fact that files are actually only
> removed when they have not been changed since the install of a to-be-removed
> package. If there are problems with upgrades, I expect only small problems in
> special as the package system supports versioned package installs. What I need
> to check is what happens after MAXINST upgrades have been passed.
>
> What really is missing is the knowledge that a package is never than another
> one and support for versioned dependencies (although there is a parser for
> versioned dependencies already).

>
>
>> 2. The concept of action scripts is a powerful one but with no control
>> it creates a complete mess. For eg every team in SUN that ever provided
>> a driver had their slightly different variant of the driver
>> install action
>> script. It was a mess of action scripts all around.
>

> This is just a result of bad management inside Sun.
>
> I was really shocked to see the mess here, but this is something we can dix and
> I already started to write standard scripts to be used via include.
>
> The worst package here is SUNWcsd that should not include a static
> name_to_major table.

>
>
>> 3. I remember a team member fixing a customer escalated bug when he
>> figured out that a particular supposedly binary search for looking up
>> pathnames was actually doing a linear search - some messy code.
>
>> This only points to the age of the codebase, 25yrs approx. Old and
>> somewhat clunky with a whole bunch of commands and libs.
>

> Isn't this something that should be be fixed with pkgserv?
>
> I am able to install the whole ON base within less than 2 minutes over the
> network, even though the packages are compressed via xz -9. It would be of
> interest to know what time you get.....
>
> Could you please fetch:
>
> http://download.berlios.de/pub/schillix-on/packages/pkgs-schillix-on.txt
>
> and follow the instructions. Note that this works directly with pkgadd over the
> network.

Will check ...

>
>> 4. The approach of keeping all pathnames in a single large text file
>> (/var/sadm/install/contents) is suboptimal. While this was updated
>> by Casper Dik sometime back there are other such things. Limitations
>> had only been patched over and over without any significant cleanups
>> or re-writes to fix old design limitations.
>

> See above, I cannot see and real problem with it today.

>
>
>> SVR4 had excellent concepts, in fact was state of the art 25yrs back.
>> The concepts are still awesome even by today's standards but
>> implementation leaves much to be desired.
>

> The packages system was created in 1982, so it is 30 years old. But not the
> time of creation matters...

Age will not matter if the code is properly maintained. How old is
the Solaris
kernel ? SVR4 code has been badly maintained due various factors including
bad management that I do not like to discuss here.

>
>> Adding missing pieces to SVR4 will mean first and foremost a repo
>> mechanism, package management and seamless upgrade support.
>

> I need to add a base URL for automated network installs, but this does not seem
> to be hard to do.

>
>> Once again trying to re-do solved problems. I was forced into the
>> unfortunate wheel re-invention for an earlier BeleniX version because
>> we did not want to touch IPS with a barge pole and we had no choice
>> in the short term but to develop Spkg:
>> http://moinakg.wordpress.com/2008/11/22/the-belenix-package-manager/
>>
>> http://belenix.svn.sourceforge.net/viewvc/belenix/trunk/spec_files/ext-sources/spkg?revision=175&view=markup
>> http://belenix.svn.sourceforge.net/viewvc/belenix/trunk/spec_files/ext-sources/spkg_mod.py?revision=395&view=markup
>> http://moinakg.wordpress.com/2008/11/22/the-belenix-package-manager/
>

> Thank you, I'll read this later....

>
>
>> It had all the useful features and brought in at least one concept that
>> "I dare say" was discussed within the IPS team later, without attribution
>> of course. However it was never intended to be a full fledged replacement
>> before people jump to find flaws in that.
>> It took about 6 months part-time effort for a single person to develop
>> compared to the 3-years of elaborate intricate complex wheel re-invention
>> with the intention to solve world package hunger and even do, surprise
>> surprise Windows package installation!
>

> I had some discussions with Dagobert Michelsen from opencsw already and he
> seems to have a lot of knowledge in this area on the svr4 package system. It
> seems that we just need to make the important decisions now and could implement
> most of the code later.

>
>
>> I want to give a wide berth to both IPS and the existing SVR4
>> "implementation".
>> I actually respect SVR4 as a concept but am not interested in doing anything
>> with its current codebase.
>

> Well, if we look at what existing OpenSolaris based distros use, there only
> seems to be IPS and from what I've seen with IPS during the past 2 years, I
> don't like to use it.

The worst case happens when I try to install a new package in my OpenIndiana
installation after a gap of say one month. Several minutes just to get a pkg
of a few hundred KBs in size over my 8MBps link. Most of the time is spent
in plan creation I think.

>
> On the other side, why take something completely new if there is experiences
> with a mature existing system?
>

My point is the mature system is missing very key pieces like package
management. Working on adding it will amount to re-doing a solved problem.
My preference is to use a ready-made tested solution. In addition I simply
do not like the SVR4 code. You can call it personal bias, but that is how it
is. I want SVR4 support but in a different way.
I want to focus my efforts to better explore Pacman and see how to add
Solaris platform and SVR4 support there. There are multiple options including
an alien kind of converter: http://joeyh.name/code/alien/
So one can auto-convert from SVR4 format to Pacman format.

Regards,
Moinak.
--
================================
http://moinakg.wordpress.com/

[Joerg Schilling]

Moinak Ghosh <moi...@belenix.org> wrote:

> >> 3. I remember a team member fixing a customer escalated bug when he
> >> figured out that a particular supposedly binary search for looking up
> >> pathnames was actually doing a linear search - some messy code.
> >
> >> This only points to the age of the codebase, 25yrs approx. Old and
> >> somewhat clunky with a whole bunch of commands and libs.
> >
> > Isn't this something that should be be fixed with pkgserv?
> >
> > I am able to install the whole ON base within less than 2 minutes over the
> > network, even though the packages are compressed via xz -9. It would be of
> > interest to know what time you get.....
> >
> > Could you please fetch:
> >
> > http://download.berlios.de/pub/schillix-on/packages/pkgs-schillix-on.txt
> >
> > and follow the instructions. Note that this works directly with pkgadd over the
> > network.
>
> Will check ...

I would be interested to see how long it takes for you.

> > The packages system was created in 1982, so it is 30 years old. But not the
> > time of creation matters...
>
> Age will not matter if the code is properly maintained. How old is
> the Solaris
> kernel ? SVR4 code has been badly maintained due various factors including
> bad management that I do not like to discuss here.

Sun in general was bad with maintaining existing software. They left a lot of
software unmaintained during the past 20 years.

However replacing existing software by new one is usually a suboptimal decision.
IPS fixed some problems from the SVr4 package system, but introduced a lot of
new bugs that never have been present with pkgadd.

> >> I actually respect SVR4 as a concept but am not interested in doing anything
> >> with its current codebase.
> >
> > Well, if we look at what existing OpenSolaris based distros use, there only
> > seems to be IPS and from what I've seen with IPS during the past 2 years, I
> > don't like to use it.
>
> The worst case happens when I try to install a new package in my OpenIndiana
> installation after a gap of say one month. Several minutes just to get a pkg
> of a few hundred KBs in size over my 8MBps link. Most of the time is spent
> in plan creation I think.

So the expected download time for the set of SchilliX-ON base pacakges should
be around 2 minutes.

I guess that a complete install will take 3 minutes.

> >
> > On the other side, why take something completely new if there is experiences
> > with a mature existing system?
> >
>
> My point is the mature system is missing very key pieces like package
> management. Working on adding it will amount to re-doing a solved problem.

pkgadd manages packages, so what do you understand by package management?

> My preference is to use a ready-made tested solution. In addition I simply
> do not like the SVR4 code. You can call it personal bias, but that is how it
> is. I want SVR4 support but in a different way.

On the other side, IPS is not ready for even be discussed with me, as I like to
use an established systen, it seems that the svr4 package system is the best
base.

> I want to focus my efforts to better explore Pacman and see how to add
> Solaris platform and SVR4 support there. There are multiple options including
> an alien kind of converter: http://joeyh.name/code/alien/
> So one can auto-convert from SVR4 format to Pacman format.

I cannot see that this support svr4 packages, but I am shure it will not
support IPS. So did you think about the fact that Illumos only supports IPS?

Jörg

--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

[Joerg Schilling]

I did not see my reply in the mailing list, so I asume that something went
wrong and I need to resend my reply.

Moinak Ghosh <moi...@belenix.org> wrote:

> >> 3. I remember a team member fixing a customer escalated bug when he
> >> figured out that a particular supposedly binary search for looking up
> >> pathnames was actually doing a linear search - some messy code.
> >
> >> This only points to the age of the codebase, 25yrs approx. Old and
> >> somewhat clunky with a whole bunch of commands and libs.
> >
> > Isn't this something that should be be fixed with pkgserv?
> >
> > I am able to install the whole ON base within less than 2 minutes over the
> > network, even though the packages are compressed via xz -9. It would be of
> > interest to know what time you get.....
> >
> > Could you please fetch:
> >
> > http://download.berlios.de/pub/schillix-on/packages/pkgs-schillix-on.txt
> >
> > and follow the instructions. Note that this works directly with pkgadd over the
> > network.
>
> Will check ...

I would be interested to see how long it takes for you.

> > The packages system was created in 1982, so it is 30 years old. But not the
> > time of creation matters...
>
> Age will not matter if the code is properly maintained. How old is
> the Solaris
> kernel ? SVR4 code has been badly maintained due various factors including
> bad management that I do not like to discuss here.

Sun in general was bad with maintaining existing software. They left a lot of
software unmaintained during the past 20 years.

However replacing existing software by new one is usually a suboptimal decision.
IPS fixed some problems from the SVr4 package system, but introduced a lot of
new bugs that never have been present with pkgadd.

> >> I actually respect SVR4 as a concept but am not interested in doing anything
> >> with its current codebase.
> >
> > Well, if we look at what existing OpenSolaris based distros use, there only
> > seems to be IPS and from what I've seen with IPS during the past 2 years, I
> > don't like to use it.
>
> The worst case happens when I try to install a new package in my OpenIndiana
> installation after a gap of say one month. Several minutes just to get a pkg
> of a few hundred KBs in size over my 8MBps link. Most of the time is spent
> in plan creation I think.

So the expected download time for the set of SchilliX-ON base pacakges should
be around 2 minutes.

I guess that a complete install will take 3 minutes.

> >

> > On the other side, why take something completely new if there is experiences
> > with a mature existing system?
> >
>
> My point is the mature system is missing very key pieces like package
> management. Working on adding it will amount to re-doing a solved problem.

pkgadd manages packages, so what do you understand by package management?

> My preference is to use a ready-made tested solution. In addition I simply
> do not like the SVR4 code. You can call it personal bias, but that is how it
> is. I want SVR4 support but in a different way.

On the other side, IPS is not ready for even be discussed with me, as I like to
use an established systen, it seems that the svr4 package system is the best
base.

> I want to focus my efforts to better explore Pacman and see how to add
> Solaris platform and SVR4 support there. There are multiple options including
> an alien kind of converter: http://joeyh.name/code/alien/
> So one can auto-convert from SVR4 format to Pacman format.

I cannot see that this support svr4 packages, but I am shure it will not
support IPS. So did you think about the fact that Illumos only supports IPS?

Jörg

--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

[Moinak Ghosh]

On Wed, Aug 22, 2012 at 4:32 PM, Joerg Schilling

<Joerg.S...@fokus.fraunhofer.de> wrote:
> Moinak Ghosh <moi...@belenix.org> wrote:
>

[...]

>> Age will not matter if the code is properly maintained. How old is
>> the Solaris
>> kernel ? SVR4 code has been badly maintained due various factors including
>> bad management that I do not like to discuss here.
>
> Sun in general was bad with maintaining existing software. They left a lot of
> software unmaintained during the past 20 years.
>
> However replacing existing software by new one is usually a suboptimal decision.
> IPS fixed some problems from the SVr4 package system, but introduced a lot of
> new bugs that never have been present with pkgadd.

IPS was a wrong strategic move by SUN. That too the IPS folks were
not willing
to listen to people who were intimately familiar with packaging and software
distribution in general. The design was broken from the start. It
was a colossal
waste of time and money by SUN.
So I cannot fully agree with your assertion that "new replacements
are usually
suboptimal". The conditions, codebase, design, technological
evolution, strategy
etc all matter.

[...]

>> My point is the mature system is missing very key pieces like package
>> management. Working on adding it will amount to re-doing a solved problem.
>
> pkgadd manages packages, so what do you understand by package management?

Many things. Please read my blog entry I posted earlier for the full details.

>
>> My preference is to use a ready-made tested solution. In addition I simply
>> do not like the SVR4 code. You can call it personal bias, but that is how it
>> is. I want SVR4 support but in a different way.
>
> On the other side, IPS is not ready for even be discussed with me, as I like to
> use an established systen, it seems that the svr4 package system is the best
> base.

I do not consider IPS worthwhile.

>
>> I want to focus my efforts to better explore Pacman and see how to add
>> Solaris platform and SVR4 support there. There are multiple options including
>> an alien kind of converter: http://joeyh.name/code/alien/
>> So one can auto-convert from SVR4 format to Pacman format.
>
> I cannot see that this support svr4 packages, but I am shure it will not
> support IPS. So did you think about the fact that Illumos only supports IPS?
>

Yes and I can pull the metadata out of the IPS package defs and use it to
construct packages in another format.

Regards,
Moinak.
--
================================
http://moinakg.wordpress.com/

[Joerg Schilling]

Moinak Ghosh <moi...@belenix.org> wrote:

> > However replacing existing software by new one is usually a suboptimal decision.
> > IPS fixed some problems from the SVr4 package system, but introduced a lot of
> > new bugs that never have been present with pkgadd.
>
> IPS was a wrong strategic move by SUN. That too the IPS folks were
> not willing
> to listen to people who were intimately familiar with packaging and software
> distribution in general. The design was broken from the start. It
> was a colossal
> waste of time and money by SUN.
> So I cannot fully agree with your assertion that "new replacements

^^^

I cannot see a relation here.... Did you mean "yet"?

> > pkgadd manages packages, so what do you understand by package management?
>
> Many things. Please read my blog entry I posted earlier for the full details.

Do you mean

"http://moinakg.wordpress.com/2008/11/22/the-belenix-package-manager/"?

I cannot see what I like to know at that place.

> I do not consider IPS worthwhile.

So we seem to agree here.

> > I cannot see that this support svr4 packages, but I am shure it will not
> > support IPS. So did you think about the fact that Illumos only supports IPS?
> >
>
> Yes and I can pull the metadata out of the IPS package defs and use it to
> construct packages in another format.

I see less meta data in IPS than I see in tge SVr4 package system. Do you like
to live with the limited information from IPS?

Jörg

--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

[Moinak Ghosh]

On Fri, Aug 24, 2012 at 8:32 PM, Joerg Schilling
<Joerg.S...@fokus.fraunhofer.de> wrote:
> Moinak Ghosh <moi...@belenix.org> wrote:
>
>> > However replacing existing software by new one is usually a suboptimal decision.
>> > IPS fixed some problems from the SVr4 package system, but introduced a lot of
>> > new bugs that never have been present with pkgadd.
>>
>> IPS was a wrong strategic move by SUN. That too the IPS folks were
>> not willing
>> to listen to people who were intimately familiar with packaging and software
>> distribution in general. The design was broken from the start. It
>> was a colossal
>> waste of time and money by SUN.
>> So I cannot fully agree with your assertion that "new replacements
> ^^^
>
> I cannot see a relation here.... Did you mean "yet"?
>

Ah, sorry for the typo. I did mean "yet".

>
>> > I cannot see that this support svr4 packages, but I am shure it will not
>> > support IPS. So did you think about the fact that Illumos only supports IPS?
>> >
>>
>> Yes and I can pull the metadata out of the IPS package defs and use it to
>> construct packages in another format.
>
> I see less meta data in IPS than I see in tge SVr4 package system. Do you like
> to live with the limited information from IPS?
>

Interesting. I thought IPS had more metadata. Can you give an example ?

Regards,
Moinak.
--
================================
http://moinakg.wordpress.com/