|
Replies:
14
-
Last Post:
May 22, 2007 12:23 AM
by: gns
|
|
|
Srichand Pendyala
srichand.pendyala@gm...
|
|
|
|
Package management for BeleniX
Posted:
May 17, 2007 12:52 PM
|
|
|
|
Hello all!
Nikhil, Sujay (of solaris-parted fame) and I have been working on
designing a package management system for use in Belenix. Tentatively
called Corona (http://launchpad.net/corona), we use a transaction
management based approach (see below), that supports multiple package
management systems. Yes you read right, multiple package managers.
I shall now describe in short the architecture we feel should work well:
Corona graphical interface (last part of the project)
| |
Corona transaction engine and glue
| |
plugin layer
| | |
pkg-build plugin apt-get plugin portage plugin
The major advantages we feel are:
1. Package management will be completely transparent to the user
2. A package distributor can choose to package his software in a way
which [s]he is comfortable with.
3. The ability to do a "rollback". More on this later.
3. No more holy wars about apt-get vs portage vs pkg-build. (of course,
apt-get rules! ;)
The transaction based approach
------------------------------
Fundamentally, all package management in Corona is only one action:
"Apply transaction". A transaction, is a list of packages and actions
that must be applied to them. For instance, if i wished to remove kde
and install gnome, a corresponding transaction would be:
- kde [dep list]
+ gnome [dep list]
To the end user however, this is transparent on some occasions and
opaque on others. It is transparent, when [s]he uses the command line to
install/remove something. So it would look like
# corona remove kde
# corona install gnome
The greatest use of the transaction based approach, comes in automating
installs and sharing programs with other people. An MSI equivalent for
BeleniX of sorts. Let say, I want to create an installer for gnome. I
would create a transaction that would go like:
[Author: Srichand]
[date: 18 May 2007]
[
+ libgnome-ui libgnome-ui-dev libgnome libgtk-2.0 .....
- libqt ...
And that would be the installer file. It would have to be executed as:
# corona apply gnome-installer-file
and that should do the trick!
Another possible use, would be to write a super-installer file, that
would contain a list of installer files itself. This can be used to
create the hard-disk installer that has also been in discussion lately.
Custom installation disks, over a base BeleniX disc could be rather easy
to create!
The package catalog on the system, is maintained as follows:
Initially, a list of all packages installed is created (say during
install time).
After each transaction, only a diff from the previous state is stored.
Also transactions may be "exported" or "imported". Thus, if I brought my
system upto a particular state on any particular day, I could merge all
the diffs upto that day and time and export it into one big transaction,
that I could either use as a backup or send around to a friend to apply
on his system. The friend, would just have to import the transaction, to
bring his system upto the same state as mine.
# corona export > my-catalog
# corona import my-catalog
Of course, there are many strategies (speed/memory optimizations) to
implement this (we've figured out 2 ways to do it so far)
Note: Transaction importing doesn't mean "upgrading" a system. It only
means that the system is brought to a *different* state. With the
transaction based approach, there is no "upgrade" option.
Rollback
--------
Probably the single greatest advantage of this system, is the rollback
feature. It allows you to "undo" an action of installation or removal.
Given the structure of the package catalog as mentioned, it is rather
easy to figure out what changes were made on which revision to the
package list. So, something like
# corona list transaction 42
Transaction 42
Author: Srichand Pendyala
Date: 18 May 2007
Added: gnome
Removed: kde
Should be very easy to implement. Extending that, to something like:
# corona rollback
Last transaction
Author: Srichand Pendyala
Date: 18 May 2007
Added: gnome
removed: kde
Should I continue? [y/n]: y
Adding kde ...................... done.
Removing gnome .................. done.
should be very doable. Even further,
# corona rollback to 40
Rolling back to transaction 40 will rollback these transactions:
Transaction 42
Author: Srichand Pendyala
Date: 18 May 2007
Added: gnome
removed: kde
Transaction 41
Author: Srichand Pendyala
Date: 18 May 2007
Added: package a
removed: package b
Transaction 40
Author: Srichand Pendyala
Date: 18 May 2007
Added: package c
removed: package d
Should I continue? [y/n]: n
and so on... Having something like this, should be rather cool! :)
Plugin based system
-------------------
A plugin based approach, will make life much easier for everyone. Should
we (the BeleniX community) at any later date decide to work on a package
management system of our own, adding support for it, will be just a
matter of writing a plugin for it.
Implementation
------------
The implementation will be in Python. The repository doesn't have any
code just as yet, just the basic directory structures for the whole
project (and very soon, the content of this thread with all useful
responses :) We're currently stuck in our 8th semester exams and won't
be free to work on corona any time before June first week!
If anyone on the list is interested in working on this, we could
probably meet up and talk about it over a coffee or two! It would be
really cool if more people can collaborate over this!
Feedback of any form is most welcome!
Should this all work out, corona could be a really powerful tool for
BeleniX!
Regards,
Srichand
--
Srichand Pendyala
MS Ramaiah Institute of Technology
http://srichand.net.in/
Better hope the life-inspector doesn't come around while you have your
life in such a mess.
_______________________________________________
ug-bosug mailing list
List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
List-Owner: mailto:ug-bosug-owner at opensolaris dot org
List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
|
|
|
Posts:
419
From:
Registered:
6/2/06
|
|
|
|
Re: Package management for BeleniX
Posted:
May 17, 2007 7:36 PM
in response to: Srichand Pendyala
|
|
I've read your post. Sounds good to me. Is there any way of taking
advantage of the existing package repositories world wide ?
I was thinking of the average user who'd say "Blastwave is around, so
are debian and gentoo. I'd rather take tested binaries/sources than be
an alpha tester".
As a developer, I'm interested in even the basic fact that you've put
some effort into thinking about package management. The one concern
that I'm voicing is that end users should use this idea, else only a
limited few of use (us and not "you alone" :) ) would use it.
I'm in a rush to catch my flight, so I won't be able to engage in a
mail discussion at least until Sunday IST. So here are a few
questions:
1. Is there anyway of taking advantage of existing repositories
(debian, gentoo, blastwave) ?
2. Is there anyway we could have migration scripts that adapt the
existing repository meta information into something that corona could
make use of ?
-- Sriram
_______________________________________________
ug-bosug mailing list
List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
List-Owner: mailto:ug-bosug-owner at opensolaris dot org
List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
|
|
|
|
|
Srichand Pendyala
srichand.pendyala@gm...
|
|
|
|
Re: Package management for BeleniX
Posted:
May 17, 2007 10:23 PM
in response to: sriramn
|
|
|
|
Hi!
On Fri, 2007-05-18 at 08:06 +0530, Sriram Narayanan wrote:
> I've read your post. Sounds good to me. Is there any way of taking
> advantage of the existing package repositories world wide ?
> I was thinking of the average user who'd say "Blastwave is around, so
> are debian and gentoo. I'd rather take tested binaries/sources than be
> an alpha tester".
Indeed! That's the main aim in fact. Lets say, we have an apt
repository. The user needs to install apt as well as the apt plugin for
Corona and finally add that repository to his /etc/apt/sources.list. Via
the plugin, Corona can then pickup and install packages directly from
that repository.
> As a developer, I'm interested in even the basic fact that you've put
> some effort into thinking about package management. The one concern
> that I'm voicing is that end users should use this idea, else only a
> limited few of use (us and not "you alone" :) ) would use it.
Corona by itself does not have any repository (although this could be
changed by standardizing any one packaging system). It needs at least
one plugin to work. So, which repository a package is being brought
from, is totally transparent to the user. All he has to do, is just add
the corresponding repositories to his sources.list or whatever that
particular repository uses.
> I'm in a rush to catch my flight, so I won't be able to engage in a
> mail discussion at least until Sunday IST. So here are a few
> questions:
>
> 1. Is there anyway of taking advantage of existing repositories
> (debian, gentoo, blastwave) ?
We need a wrapper plugin for each of these systems and we can use these
packages directly. That is the main intention, since corona doesn't have
its own package management system. It will rely on existing repositories
such as blastwave and pkgbuild.
The only issue with using multiple repositories, however, is binary
compatibility. For instance, Blastwave's packages are backward
compatible upto solaris 8(?) and are built against the sun toolchain.
Nexenta's repositories are built against the GNU toolchain. So although
the same package is available from both places, they won't be binary
compatible. This is one of the few unfinished pieces that we need to
figure out.
> 2. Is there anyway we could have migration scripts that adapt the
> existing repository meta information into something that corona could
> make use of ?
Repository meta information, will be handled by the package management
system itself.
Lets say, we want to install a package called "foo-bar".
So to corona, the installation would look like:
# corona install foo-bar
Lets say an apt-get plugin for corona is installed. Corona will then
internally query apt-get about the existence of that package. Should the
package be present, corona will request apt-get to install it along with
its list of dependencies. Of course, this part is entirely transparent
to the user.
Binary compatibility is going to be a big issue. Thus, supporting
Blastwave as well as another repository is going to be rather difficult.
For BeleniX, we will need to create our own repository (probably, say
pkgbuild since it uses the .pkg format itself), or be binary compatible
with another OpenSolaris distribution. The former is probably going to
be much easier to setup.
> -- Sriram
Regards,
Srichand
> _______________________________________________
> ug-bosug mailing list
> List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
> List-Owner: mailto:ug-bosug-owner at opensolaris dot org
> List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
_______________________________________________
ug-bosug mailing list
List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
List-Owner: mailto:ug-bosug-owner at opensolaris dot org
List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
|
|
|
|
|
Posts:
412
From:
Bangalore
Registered:
3/29/07
|
|
|
|
Re: Package management for BeleniX
Posted:
May 17, 2007 10:56 PM
in response to: Srichand Pendyala
|
|
|
|
Would it not be a good idea to write a wrapper for the SVR4 packaging tools?
The tool would ideally resolve dependences and the do a "pkgadd -d
http://whatever"
Infact I am working on such a tool for my personal use.
I use it to install KDE 3.4.3, vim70 , oss and solaris codec pack on my
system.
With Stefan's help , making packges for Qt 4.2.2 and I shall present
these packages as a case study, in a couple of days.
Srichand Pendyala wrote:
> Hi!
>
> On Fri, 2007-05-18 at 08:06 +0530, Sriram Narayanan wrote:
>
>> I've read your post. Sounds good to me. Is there any way of taking
>> advantage of the existing package repositories world wide ?
>> I was thinking of the average user who'd say "Blastwave is around, so
>> are debian and gentoo. I'd rather take tested binaries/sources than be
>> an alpha tester".
>>
>
> Indeed! That's the main aim in fact. Lets say, we have an apt
> repository. The user needs to install apt as well as the apt plugin for
> Corona and finally add that repository to his /etc/apt/sources.list. Via
> the plugin, Corona can then pickup and install packages directly from
> that repository.
>
>
>> As a developer, I'm interested in even the basic fact that you've put
>> some effort into thinking about package management. The one concern
>> that I'm voicing is that end users should use this idea, else only a
>> limited few of use (us and not "you alone" :) ) would use it.
>>
>
> Corona by itself does not have any repository (although this could be
> changed by standardizing any one packaging system). It needs at least
> one plugin to work. So, which repository a package is being brought
> from, is totally transparent to the user. All he has to do, is just add
> the corresponding repositories to his sources.list or whatever that
> particular repository uses.
>
>
>> I'm in a rush to catch my flight, so I won't be able to engage in a
>> mail discussion at least until Sunday IST. So here are a few
>> questions:
>>
>> 1. Is there anyway of taking advantage of existing repositories
>> (debian, gentoo, blastwave) ?
>>
>
> We need a wrapper plugin for each of these systems and we can use these
> packages directly. That is the main intention, since corona doesn't have
> its own package management system. It will rely on existing repositories
> such as blastwave and pkgbuild.
>
> The only issue with using multiple repositories, however, is binary
> compatibility. For instance, Blastwave's packages are backward
> compatible upto solaris 8(?) and are built against the sun toolchain.
> Nexenta's repositories are built against the GNU toolchain. So although
> the same package is available from both places, they won't be binary
> compatible. This is one of the few unfinished pieces that we need to
> figure out.
>
>
>> 2. Is there anyway we could have migration scripts that adapt the
>> existing repository meta information into something that corona could
>> make use of ?
>>
>
> Repository meta information, will be handled by the package management
> system itself.
> Lets say, we want to install a package called "foo-bar".
>
> So to corona, the installation would look like:
>
> # corona install foo-bar
>
> Lets say an apt-get plugin for corona is installed. Corona will then
> internally query apt-get about the existence of that package. Should the
> package be present, corona will request apt-get to install it along with
> its list of dependencies. Of course, this part is entirely transparent
> to the user.
>
> Binary compatibility is going to be a big issue. Thus, supporting
> Blastwave as well as another repository is going to be rather difficult.
> For BeleniX, we will need to create our own repository (probably, say
> pkgbuild since it uses the .pkg format itself), or be binary compatible
> with another OpenSolaris distribution. The former is probably going to
> be much easier to setup.
>
>
>> -- Sriram
>>
>
> Regards,
> Srichand
>
>
>> _______________________________________________
>> ug-bosug mailing list
>> List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
>> List-Owner: mailto:ug-bosug-owner at opensolaris dot org
>> List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> ug-bosug mailing list
>> List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
>> List-Owner: mailto:ug-bosug-owner at opensolaris dot org
>> List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
_______________________________________________
ug-bosug mailing list
List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
List-Owner: mailto:ug-bosug-owner at opensolaris dot org
List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
|
|
|
|
|
Srichand Pendyala
srichand.pendyala@gm...
|
|
|
|
Re: Package management for BeleniX
Posted:
May 18, 2007 6:05 AM
in response to: manishch
|
|
|
|
Hi!
On Fri, 2007-05-18 at 11:26 +0530, Manish Chakravarty wrote:
> Would it not be a good idea to write a wrapper for the SVR4 packaging tools?
>
> The tool would ideally resolve dependences and the do a "pkgadd -d
> http://whatever"
>
> Infact I am working on such a tool for my personal use.
>
> I use it to install KDE 3.4.3, vim70 , oss and solaris codec pack on my
> system.
>
> With Stefan's help , making packges for Qt 4.2.2 and I shall present
> these packages as a case study, in a couple of days.
Nice!! I guess once your code is ready, we could just 'rip it off' and
write a plugin for it! :)
Is your code available anyplace online right now?
Thanks!
Regards,
Srichand
--
Srichand Pendyala
MS Ramaiah Institute of Technology
http://srichand.net.in/
Tomorrow, you can be anywhere.
_______________________________________________
ug-bosug mailing list
List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
List-Owner: mailto:ug-bosug-owner at opensolaris dot org
List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
|
|
|
|
|
Posts:
412
From:
Bangalore
Registered:
3/29/07
|
|
|
|
Re: Package management for BeleniX
Posted:
May 18, 2007 6:22 AM
in response to: Srichand Pendyala
|
|
|
|
Hi Srichand,
I had a discussion with Venky today.
He suggested to look into SunFreeware.. as in use SunFreeware as the
repository to pull packages from it.
Once I am sure about what is the right approach, I'll surely share it so
that you guys can rip it off :)
Thanks
Manish
Srichand Pendyala wrote:
> Hi!
>
> On Fri, 2007-05-18 at 11:26 +0530, Manish Chakravarty wrote:
>
>> Would it not be a good idea to write a wrapper for the SVR4 packaging tools?
>>
>> The tool would ideally resolve dependences and the do a "pkgadd -d
>> http://whatever"
>>
>> Infact I am working on such a tool for my personal use.
>>
>> I use it to install KDE 3.4.3, vim70 , oss and solaris codec pack on my
>> system.
>>
>> With Stefan's help , making packges for Qt 4.2.2 and I shall present
>> these packages as a case study, in a couple of days.
>>
>
> Nice!! I guess once your code is ready, we could just 'rip it off' and
> write a plugin for it! :)
>
> Is your code available anyplace online right now?
>
> Thanks!
>
> Regards,
> Srichand
>
>
_______________________________________________
ug-bosug mailing list
List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
List-Owner: mailto:ug-bosug-owner at opensolaris dot org
List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
|
|
|
|
|
Posts:
1,223
From:
India
Registered:
7/15/05
|
|
|
|
Re: Package management for BeleniX
Posted:
May 18, 2007 7:50 AM
in response to: manishch
|
|
Folks,
Big email but required reading for all pondering packaging and software
repository issues on OpenSolaris. I have tried to sum up the current
situation
and point the way forward:
Manish Chakravarty wrote:
> Hi Srichand,
>
> I had a discussion with Venky today.
> He suggested to look into SunFreeware.. as in use SunFreeware as the
> repository to pull packages from it.
> Once I am sure about what is the right approach, I'll surely share it so
> that you guys can rip it off :)
>
SunFreeware and Blastwave both have their pros and cons:
SunFreeware:
* Installs into /usr/local
* Separate packages for separate Solaris releases means it links with the
stuff already in the system and does not duplicate required
software and more
able to utilize new Solaris features.
* Can be a boon when you just need that one package but do not want to
pull a truckload of dependencies. The previous property implies this
* Repository has limited number of packages
* Dependency information/resolution non-existent
* Maintained mostly by one person
Blastwave
* Installs into /opt/csw
* The Kitchen Sink of Solaris packages. Contains > 1500 packages for
Solaris
* Actively maintained by a community of contributors
* Full dependency resolution and apt-get like interface via pkg-get
* All binary packages are built on Solaris 8! So cannot utilize new
Solaris features
like libXft for font rendering resulting in for eg. ugly fonts in KDE.
* Maintains it's own parallel stack of all software dependencies
resulting a huge
dependency list. So all extra stuff in latest Solaris releases
like JDS are duplicated
by Blastwave.
* Doing a pkg-get eats bandwidth like a mad hog and pulls endless
series of
packages via dependency resolution.
Thus none of the repositories available today satisfy the needs of
OpenSolaris users.
Typically no duplication. Install by default into /usr. Install
conflicting binaries like
GNU coreutils under /usr/gnu. Use the latest features: Freetype2,
Fontconfig, libXft
Xorg 7.2 etc. etc.
SUN used to distribute a prebuilt set of binary FOSS packages called
the Companion
CD that had some of the desired properties and installed into
/opt/sfw. That has been
discontinued and the Companion CD build env/patches has been made into a
community project:
http://www.opensolaris.org/os/project/companion/
This is now being maintained by Steven Christensen that same guy who
maintains
SunFreeware. This is a bigger repository and contains more stuff. But
much of the
stuff is outdated and being slowly updated.
The big problem with CCD is the custom Makefile based build
framework. It takes
a lot of effort to update/add software there! The Makefiles are
obtuse and obscure!
So what do we do now !!
There is an excellent tool called Pkgbuild:
http://pkgbuild.sourceforge.net/
This tool is used to build the complete JDS(GNOME) on OpenSolaris. it
builds Solaris SVR4 packages from RPM Spec files. it can do the
following:
- Load the spec file
- Download the source tarball
- Unpack it and apply patches
- Build, Install, Package
- Resolve dependencies
Not unlike Emerge eh! The builds are driven by Custom OpenSolaris -
specific Spec files that include the original Spec file and add in
OpenSolaris
specific definitions.
The JDS folks started another effort called Spec-Files-Extra:
http://pkgbuild.sourceforge.net/spec-files-extra/
This is a repository of OpenSolaris Spec files *and* patches that
will allow
one to easily build FOSS on OpenSolaris. But this is a source only
repository. Again not unlike Emerge eh :)
Now the best option will be to merge the Companion CD and Spec-Files
-Extra projects to create a one-true-unified repository for *both* source
packaging *and* binary packaging. There is some effort that is going to
start in the community related to this.
In the meantime I strongly feel that it is in everyone's best
interests to start
using Pkgbuild and contributing to the Spec-Files-Extra repository. There
are others in the community actively contributing to this repository. At
least we get source packaging a-la Emerge. But Pkgbuild needs some
additions to make the dependency resolution automatic and can be helped
with a good Python based GUI.
The excellent packaging proposal that has been mooted by Srichand and
friends needs to integrate Pkgbuild into the framework.
After BeleniX 0.6 release I am going to move the complete BeleniX FOSS
build framework over to Pkgbuild and contribute the Spec-Files-Extra
repository. BeleniX 0.6.1 will come with 100% complete SVR4 packaging.
So this is also important when Manish is mucking around with KDE on
Solaris. A complete set of Spec files that allow one to transparently
build
KDE on OpenSolaris will be simply *Awesome*.
Regards,
Moinak.
> Thanks
> Manish
>
> Srichand Pendyala wrote:
>
>> Hi!
>>
>> On Fri, 2007-05-18 at 11:26 +0530, Manish Chakravarty wrote:
>>
>>
>>> Would it not be a good idea to write a wrapper for the SVR4 packaging tools?
>>>
>>> The tool would ideally resolve dependences and the do a "pkgadd -d
>>> http://whatever"
>>>
>>> Infact I am working on such a tool for my personal use.
>>>
>>> I use it to install KDE 3.4.3, vim70 , oss and solaris codec pack on my
>>> system.
>>>
>>> With Stefan's help , making packges for Qt 4.2.2 and I shall present
>>> these packages as a case study, in a couple of days.
>>>
>>>
>> Nice!! I guess once your code is ready, we could just 'rip it off' and
>> write a plugin for it! :)
>>
>> Is your code available anyplace online right now?
>>
>> Thanks!
>>
>> Regards,
>> Srichand
>>
>>
>>
>> _______________________________________________
>> ug-bosug mailing list
>> List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
>> List-Owner: mailto:ug-bosug-owner at opensolaris dot org
>> List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
>>
_______________________________________________
ug-bosug mailing list
List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
List-Owner: mailto:ug-bosug-owner at opensolaris dot org
List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
|
|
|
|
|
Srichand Pendyala
srichand.pendyala@gm...
|
|
|
|
Re: Package management for BeleniX
Posted:
May 18, 2007 8:09 AM
in response to: moinakg
|
|
|
|
Hi,
On Fri, 2007-05-18 at 20:20 +0530, Moinak Ghosh wrote:
> There is an excellent tool called Pkgbuild:
> http://pkgbuild.sourceforge.net/
> This tool is used to build the complete JDS(GNOME) on OpenSolaris. it
> builds Solaris SVR4 packages from RPM Spec files. it can do the
> following:
I probably missed this part from my initial email, but pkgbuild is a
simply awesome way of doing things. Source based installs that use a
spec file are the way to go! I guess a pkgbuild plugin will be one of
the first to come up.
> After BeleniX 0.6 release I am going to move the complete BeleniX FOSS
> build framework over to Pkgbuild and contribute the Spec-Files-Extra
> repository. BeleniX 0.6.1 will come with 100% complete SVR4 packaging.
I hope we should be done by the 0.6.1 release. But I guess a more
realistic time frame, will be the 0.7 release.
Should we consider making the SVR4 format a "default" for Corona?
> Regards,
> Moinak.
Regards,
Srichand
--
Srichand Pendyala
MS Ramaiah Institute of Technology
http://srichand.net.in/
You will gain money by an illegal action.
_______________________________________________
ug-bosug mailing list
List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
List-Owner: mailto:ug-bosug-owner at opensolaris dot org
List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
|
|
|
|
|
Posts:
844
From:
INDIA
Registered:
2/10/06
|
|
|
|
Re: Package management for BeleniX
Posted:
May 18, 2007 1:37 AM
in response to: Srichand Pendyala
|
|
Excellent initiative !
On 5/18/07, Srichand Pendyala <srichand dot pendyala at gmail dot com> wrote:
> Hello all!
>
> Nikhil, Sujay (of solaris-parted fame) and I have been working on
> designing a package management system for use in Belenix. Tentatively
> called Corona (http://launchpad.net/corona), we use a transaction
> management based approach (see below), that supports multiple package
> management systems. Yes you read right, multiple package managers.
>
> I shall now describe in short the architecture we feel should work well:
>
> Corona graphical interface (last part of the project)
> | |
> Corona transaction engine and glue
> | |
> plugin layer
> | | |
> pkg-build plugin apt-get plugin portage plugin
>
Supporting multiple formats can happen in 2 ways:
[1] Have one natively supported system(ex deb for debian). Use
conversion utility to convert other formats to the native format and
use the package after conversion.
Repositories are managed using the native system.
[2] Use a common engine which has package independent generic
interfaces. Use package specific converters (plugins in your case)
that will do the conversion.
You have chosen option [2].
In option [1], if you make the package conversion part transparent to
the user, the user experience will be similar to option [2]. Added
advantage is that you can reuse many of the conversion
utilities/libraries already available.
Ex: extend alien (http://kitenet.net/~joey/code/alien and
http://en.wikipedia.org/wiki/Alien_%28computing%29) to support SVR4
and use its libs internally for plugins.
Option [1] provides better control, easier handling of software
updates. At the same time option [2] can be provided at the user level
with option [1] style architecture internally.
Also going by option [1] will mean you can use some existing
code-bases and get a quicker working code that users can use and
provide you good feedback.
Keeping the engine completely independent of any of the existing
packages might mean considerable effort plus difficulties in
maintaining all the plug-in with same quality of working.
Your choice here will probably affect how you define a transaction and
how you manage it.
As pointed by Manish, handling dependencies will be an important
benefit that you can provide to the user (something on the lines of
synaptic).
Apart from binary compatibility there are other issues to consider,
[1] Not all packaging systems provide same degree of control. Will
corona reduce to minimum common denominator.
[2] At the gui level, will I be allowed to choose kde-libs from one
pkg system, desktop from another, i10 packages from yet another
system.
Note that even if this is not allowed in a single transaction, the
user can still do it using multiple transactions since underlying
packages are transparent to the user.
[3] How to detect if a file from one packaging system tries to
overwrite that from another.
[4] If I have installed a gcc libs from one pkg system as part of an
installing an app. Now if I need the gcc from another pkg system, will
I be asked to reuse the lib or install another copy. Extending this,
if it is the former, now if I remove the application and gcc libs, how
is removal of gcc-libs prevented. If it is the latter, there is
duplication of software bases - one of the cribs about blastwave.
<snip>
>
> The transaction based approach
> ------------------------------
>
> Fundamentally, all package management in Corona is only one action:
> "Apply transaction". A transaction, is a list of packages and actions
> that must be applied to them. For instance, if i wished to remove kde
> and install gnome, a corresponding transaction would be:
>
> - kde [dep list]
> + gnome [dep list]
>
I presume dependency resolution will be provided by your package
management system and the user does not need to identify [dep list]
You may want to consider *A Transaction* as an atomic operation that
leaves the system in a consistent state. A set of transactions can be
*one user operation*. Try to provide a commit and rollback at this
level, but this might not always to possible.
If you define "remove kde" and "install gnome" as one transaction,
this might be too many steps internally to manage (especially the
rollback).
<snip>
>
> The package catalog on the system, is maintained as follows:
>
> Initially, a list of all packages installed is created (say during
> install time).
> After each transaction, only a diff from the previous state is stored.
>
There is a potential problem here. You can expect any power user to
use other packaging system directly. For ex: the user may
install/remove/update pkg1 using corona and pkg2 using the SVR4 system
directly.
You can choose to say, corona *must* be the way everybody manages
softwares on their system, but you should think through this scenario
in some more detail.
> With the transaction based approach, there is no "upgrade" option.
>
???
> Rollback
> --------
>
> Probably the single greatest advantage of this system, is the rollback
> feature. It allows you to "undo" an action of installation or removal.
> Given the structure of the package catalog as mentioned, it is rather
> easy to figure out what changes were made on which revision to the
> package list.
>
The basic idea is elegant and good.
Good amount of thought and work might be required to ensure
consistency of the system.
Transaction 40 + 41
must be equivalent to
Transaction 40 + 41 + 42 + 43 and Rollback 43 + 42
> Implementation
> ------------
> The implementation will be in Python.
If you consider option [1] listed earlier favorably, then you will
have a C backed interfacing with the packaging systems and python
frontend and a part of the engine for text processing and GUI.
regards
Shiv
_______________________________________________
ug-bosug mailing list
List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
List-Owner: mailto:ug-bosug-owner at opensolaris dot org
List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
|
|
|
|
|
Srichand Pendyala
srichand.pendyala@gm...
|
|
|
|
Re: Package management for BeleniX
Posted:
May 18, 2007 6:02 AM
in response to: gns
|
|
|
|
On Fri, 2007-05-18 at 14:07 +0530, G N S wrote:
> Excellent initiative !
Thank you!
> Supporting multiple formats can happen in 2 ways:
> [1] Have one natively supported system(ex deb for debian). Use
> conversion utility to convert other formats to the native format and
> use the package after conversion.
> Repositories are managed using the native system.
>
> [2] Use a common engine which has package independent generic
> interfaces. Use package specific converters (plugins in your case)
> that will do the conversion.
>
> You have chosen option [2].
>
> In option [1], if you make the package conversion part transparent to
> the user, the user experience will be similar to option [2]. Added
> advantage is that you can reuse many of the conversion
> utilities/libraries already available.
> Ex: extend alien (http://kitenet.net/~joey/code/alien and
> http://en.wikipedia.org/wiki/Alien_%28computing%29) to support SVR4
> and use its libs internally for plugins.
> s
> Option [1] provides better control, easier handling of software
> updates. At the same time option [2] can be provided at the user level
> with option [1] style architecture internally.
> Also going by option [1] will mean you can use some existing
> code-bases and get a quicker working code that users can use and
> provide you good feedback.
>
> Keeping the engine completely independent of any of the existing
> packages might mean considerable effort plus difficulties in
> maintaining all the plug-in with same quality of working.
While both options are technically feasible, I am not sure how easy it
would be to implement option 1. Alien is rather experimental and the man
page even insists that alien shouldn't be used for important system
packages.
That said, even if such a modification is possible, messing with alien
for each new format is not going to be the easiest of things.
Option 1, will require a major effort into rewriting lots of Alien
itself and rewriting a lot of pre existing code. For instance, code that
handles the pkg format is already there, in the form of pkgadd.
Rewriting that again, in Perl while attempting to extend Alien may be a
somewhat difficult task that will still not be 100% accurate.
In any case, fetching the package from different repositories is still
non-trivial. So a package manager will still be needed.
> Your choice here will probably affect how you define a transaction and
> how you manage it.
>
> As pointed by Manish, handling dependencies will be an important
> benefit that you can provide to the user (something on the lines of
> synaptic).
>
> Apart from binary compatibility there are other issues to consider,
> [1] Not all packaging systems provide same degree of control. Will
> corona reduce to minimum common denominator.
Could you expand on this a bit more? How do you mean "control"?
> [2] At the gui level, will I be allowed to choose kde-libs from one
> pkg system, desktop from another, i10 packages from yet another
> system.
> Note that even if this is not allowed in a single transaction, the
> user can still do it using multiple transactions since underlying
> packages are transparent to the user.
As long as the packages are binary compatible, that shouldn't be a
problem. If multiple package managers are being used, the the user
should mention a hierarchy of selection. But yes, it should be possible
to have a "force" mode, where corona will use a particular repository
for a package.
The gui will just be another wrapper over the final system. Something
like what synaptic is to apt. Working on the GUI is probably the last
part of the project.
> [3] How to detect if a file from one packaging system tries to
> overwrite that from another.
Do you mean a file, as in /usr/lib/mylib.so.1, or a package as in
libmylib-dev-0.0.1?
Corona does not track individual files, but instead, the package that
contains the file.
Corona will have its own list of packages that have been installed,
which will always be checked against. So if you want to install a
package that has already been installed then no action will be taken.
> [4] If I have installed a gcc libs from one pkg system as part of an
> installing an app. Now if I need the gcc from another pkg system, will
> I be asked to reuse the lib or install another copy. Extending this,
> if it is the former, now if I remove the application and gcc libs, how
> is removal of gcc-libs prevented. If it is the latter, there is
> duplication of software bases - one of the cribs about blastwave.
I am not sure I have totally understood your question.
I'll answer the second part though:
Duplication of software bases strictly has to be avoided. Which is why I
am personally not very keen on supporting blastwave. But that is a
peripheral issue for the moment. Getting the core engine and the glue
working is both urgent and important.
> <snip>
> >
> > The transaction based approach
> > ------------------------------
> >
> > Fundamentally, all package management in Corona is only one action:
> > "Apply transaction". A transaction, is a list of packages and actions
> > that must be applied to them. For instance, if i wished to remove kde
> > and install gnome, a corresponding transaction would be:
> >
> > - kde [dep list]
> > + gnome [dep list]
> >
>
> I presume dependency resolution will be provided by your package
> management system and the user does not need to identify [dep list]
> You may want to consider *A Transaction* as an atomic operation that
> leaves the system in a consistent state. A set of transactions can be
> *one user operation*. Try to provide a commit and rollback at this
> level, but this might not always to possible.
> If you define "remove kde" and "install gnome" as one transaction,
> this might be too many steps internally to manage (especially the
> rollback).
Dependency handling is the package management system's problem and has
to be transparent to the user.
With that definition of transaction, the opportunities for a user to
mess up the system are rather large, especially with rollback. If for
instance the user asks to install package a, which depends on b, c, d
and e. Then, say transactions 42, 43, 44, and 45 are used to install the
dependencies and 46 installs package a.
If a user does a rollback to transaction 43, there will be a degree of
inconsistency. Although not fatal (and possibly easily correctable too),
it does leave the catalog in a dirty sort of state.
If we define a transaction as a "single user operation", then in a
computer science sense, it is a simple tree traversal (two trees, one
for installation and one for removal) and hence atomic in itself. Until
and unless the root node has been visited, the transaction cannot be
deemed complete. A single transaction, say transaction 42, will install
all of gnome and remove all of kde. Thus a rollback, is only a reverse
traversal of the tree and will be quite easy to implement. More
importantly, it does not give the user any scope to leave the catalog in
an inconsistent state, however insignificant the inconsistency is.
> <snip>
> >
> > The package catalog on the system, is maintained as follows:
> >
> > Initially, a list of all packages installed is created (say during
> > install time).
> > After each transaction, only a diff from the previous state is stored.
> >
> There is a potential problem here. You can expect any power user to
> use other packaging system directly. For ex: the user may
> install/remove/update pkg1 using corona and pkg2 using the SVR4 system
> directly.
>
> You can choose to say, corona *must* be the way everybody manages
> softwares on their system, but you should think through this scenario
> in some more detail.
The basic premise, is that corona is a somewhat transparent wrapper over
existing package management systems. Hence it is very prudent to assume
that the user will, at some point, unknown to corona, invoke the
underlying package management system itself.
Since the package handling is itself handled by the underlying system,
that should be okay. Adding a check to see, for example, if the apt
catalog on the system has changed at each invocation of corona, is an
implementation issue and not a major hassle.
> > With the transaction based approach, there is no "upgrade" option.
> >
>
> ???
The word "upgrade", means to install newer versions of a specific
package. With a transaction based approach, we are only applying a
transaction. Moving from version 1.0 to 2.0, is a transaction. As is
moving from 2.0 to 1.0.
Yes, the user will have a command option that says "upgrade", but
internally, that need not be treated very differently.
> > Rollback
> > --------
> >
> > Probably the single greatest advantage of this system, is the rollback
> > feature. It allows you to "undo" an action of installation or removal.
> > Given the structure of the package catalog as mentioned, it is rather
> > easy to figure out what changes were made on which revision to the
> > package list.
> >
>
> The basic idea is elegant and good.
Thank you! Comments like this are really encouraging! :)
> Good amount of thought and work might be required to ensure
> consistency of the system.
> Transaction 40 + 41
> must be equivalent to
> Transaction 40 + 41 + 42 + 43 and Rollback 43 + 42
Yes, this will need to be carefully worked upon.
> > Implementation
> > ------------
> > The implementation will be in Python.
> If you consider option [1] listed earlier favorably, then you will
> have a C backed interfacing with the packaging systems and python
> frontend and a part of the engine for text processing and GUI.
Alien is written in Perl, yum is written in Python and apt-get is
written in C. Writing wrappers over all of them into one single language
(using SWIG, for instance) should simplify further development. pkg-get
however, is written using ksh. Porting it to any language will be
considerable work (I've been reading the code for sometime now. A
suitably modified pkg-get for testing purposes is in the mainline of
corona on launchpad.)
I chose Python, because I feel it lets me concentrate on the algorithm
and data structure, more than the language or its syntax. Not to mention
the fact that there's an awesome plugin for Eclipse!
> regards
> Shiv
Regards,
Srichand
--
Srichand Pendyala
MS Ramaiah Institute of Technology
http://srichand.net.in/
A classic is something that everyone wants to have read
and nobody wants to read.
-- Mark Twain, "The Disappearance of Literature"
_______________________________________________
ug-bosug mailing list
List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
List-Owner: mailto:ug-bosug-owner at opensolaris dot org
List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
|
|
|
|
|
Posts:
207
From:
Bangalore
Registered:
12/4/05
|
|
|
|
Re: Package management for BeleniX
Posted:
May 18, 2007 5:40 AM
in response to: Srichand Pendyala
|
|
Hey Srichand and Team,
Nice ! Could we have this as the topic in one of our upcoming BOSUG
meets ? You could get early feedback and more expansive ideas :-)
Some of what you propose overlaps with the 'Smart Package Manager':
http://labix.org/smart
Maybe you have already taken a look at it and found it unsuitable ?
Cheers,
Ananth
Srichand Pendyala wrote:
> Hello all!
>
> Nikhil, Sujay (of solaris-parted fame) and I have been working on
> designing a package management system for use in Belenix. Tentatively
> called Corona (http://launchpad.net/corona), we use a transaction
> management based approach (see below), that supports multiple package
> management systems. Yes you read right, multiple package managers.
>
> I shall now describe in short the architecture we feel should work well:
>
> Corona graphical interface (last part of the project)
> | |
> Corona transaction engine and glue
> | |
> plugin layer
> | | |
> pkg-build plugin apt-get plugin portage plugin
>
>
> The major advantages we feel are:
> 1. Package management will be completely transparent to the user
> 2. A package distributor can choose to package his software in a way
> which [s]he is comfortable with.
> 3. The ability to do a "rollback". More on this later.
> 3. No more holy wars about apt-get vs portage vs pkg-build. (of course,
> apt-get rules! ;)
>
>
> The transaction based approach
> ------------------------------
>
> Fundamentally, all package management in Corona is only one action:
> "Apply transaction". A transaction, is a list of packages and actions
> that must be applied to them. For instance, if i wished to remove kde
> and install gnome, a corresponding transaction would be:
>
> - kde [dep list]
> + gnome [dep list]
>
> To the end user however, this is transparent on some occasions and
> opaque on others. It is transparent, when [s]he uses the command line to
> install/remove something. So it would look like
>
> # corona remove kde
> # corona install gnome
>
> The greatest use of the transaction based approach, comes in automating
> installs and sharing programs with other people. An MSI equivalent for
> BeleniX of sorts. Let say, I want to create an installer for gnome. I
> would create a transaction that would go like:
>
> [Author: Srichand]
> [date: 18 May 2007]
> [
> + libgnome-ui libgnome-ui-dev libgnome libgtk-2.0 .....
> - libqt ...
>
> And that would be the installer file. It would have to be executed as:
>
> # corona apply gnome-installer-file
>
> and that should do the trick!
> Another possible use, would be to write a super-installer file, that
> would contain a list of installer files itself. This can be used to
> create the hard-disk installer that has also been in discussion lately.
> Custom installation disks, over a base BeleniX disc could be rather easy
> to create!
>
> The package catalog on the system, is maintained as follows:
>
> Initially, a list of all packages installed is created (say during
> install time).
> After each transaction, only a diff from the previous state is stored.
>
> Also transactions may be "exported" or "imported". Thus, if I brought my
> system upto a particular state on any particular day, I could merge all
> the diffs upto that day and time and export it into one big transaction,
> that I could either use as a backup or send around to a friend to apply
> on his system. The friend, would just have to import the transaction, to
> bring his system upto the same state as mine.
>
> # corona export > my-catalog
> # corona import my-catalog
>
> Of course, there are many strategies (speed/memory optimizations) to
> implement this (we've figured out 2 ways to do it so far)
>
> Note: Transaction importing doesn't mean "upgrading" a system. It only
> means that the system is brought to a *different* state. With the
> transaction based approach, there is no "upgrade" option.
>
> Rollback
> --------
>
> Probably the single greatest advantage of this system, is the rollback
> feature. It allows you to "undo" an action of installation or removal.
> Given the structure of the package catalog as mentioned, it is rather
> easy to figure out what changes were made on which revision to the
> package list. So, something like
>
> # corona list transaction 42
> Transaction 42
> Author: Srichand Pendyala
> Date: 18 May 2007
> Added: gnome
> Removed: kde
>
> Should be very easy to implement. Extending that, to something like:
>
> # corona rollback
> Last transaction
> Author: Srichand Pendyala
> Date: 18 May 2007
> Added: gnome
> removed: kde
> Should I continue? [y/n]: y
>
> Adding kde ...................... done.
> Removing gnome .................. done.
>
> should be very doable. Even further,
>
> # corona rollback to 40
> Rolling back to transaction 40 will rollback these transactions:
>
> Transaction 42
> Author: Srichand Pendyala
> Date: 18 May 2007
> Added: gnome
> removed: kde
>
> Transaction 41
> Author: Srichand Pendyala
> Date: 18 May 2007
> Added: package a
> removed: package b
>
> Transaction 40
> Author: Srichand Pendyala
> Date: 18 May 2007
> Added: package c
> removed: package d
>
> Should I continue? [y/n]: n
>
> and so on... Having something like this, should be rather cool! :)
>
> Plugin based system
> -------------------
>
> A plugin based approach, will make life much easier for everyone. Should
> we (the BeleniX community) at any later date decide to work on a package
> management system of our own, adding support for it, will be just a
> matter of writing a plugin for it.
>
> Implementation
> ------------
>
> The implementation will be in Python. The repository doesn't have any
> code just as yet, just the basic directory structures for the whole
> project (and very soon, the content of this thread with all useful
> responses :) We're currently stuck in our 8th semester exams and won't
> be free to work on corona any time before June first week!
>
> If anyone on the list is interested in working on this, we could
> probably meet up and talk about it over a coffee or two! It would be
> really cool if more people can collaborate over this!
>
> Feedback of any form is most welcome!
>
> Should this all work out, corona could be a really powerful tool for
> BeleniX!
>
> Regards,
> Srichand
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ug-bosug mailing list
> List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
> List-Owner: mailto:ug-bosug-owner at opensolaris dot org
> List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
_______________________________________________
ug-bosug mailing list
List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
List-Owner: mailto:ug-bosug-owner at opensolaris dot org
List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
|
|
|
|
|
Srichand Pendyala
srichand.pendyala@gm...
|
|
|
|
Re: Package management for BeleniX
Posted:
May 18, 2007 8:19 AM
in response to: ananth
|
|
|
|
On Fri, 2007-05-18 at 18:17 +0530, Ananth Shrinivas wrote:
> Hey Srichand and Team,
>
> Nice ! Could we have this as the topic in one of our upcoming BOSUG
> meets ? You could get early feedback and more expansive ideas :-)
Sure! But we should probably get some initial code done by then, at the
very least. Considering we won't be able to work on it anytime before
June first week, that could take some time.
But feedback and ideas are something we are in dire need of! Shiv has
already raised some interesting points and has given us some more
options to consider. The more, the merrier!
> Some of what you propose overlaps with the 'Smart Package Manager':
> http://labix.org/smart
>
> Maybe you have already taken a look at it and found it unsuitable ?
>
I must confess, I haven't ever seen it before! Seeing the word
"transaction" on their page made my heart sink to my boots!
But yes, there are sufficient and large differences between their work
and ours. They concentrate more on "smart transactions", attempting to
optimize an installation where as we concentrate on managing
transactions for atomicity (to implement things like rollback and
transaction export/import)
Package manager agnosticism is (an optional) byproduct in Corona, while
its a major focus on their system.
> Cheers,
> Ananth
Regards,
Srichand
_______________________________________________
ug-bosug mailing list
List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
List-Owner: mailto:ug-bosug-owner at opensolaris dot org
List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
|
|
|
|
|
Posts:
207
From:
Bangalore
Registered:
12/4/05
|
|
|
|
Re: Package management for BeleniX
Posted:
May 18, 2007 9:15 AM
in response to: Srichand Pendyala
|
|
Hey Srichand,
Srichand Pendyala wrote:
>> Some of what you propose overlaps with the 'Smart Package Manager':
>> http://labix.org/smart
>>
>> Maybe you have already taken a look at it and found it unsuitable ?
>>
>
> I must confess, I haven't ever seen it before! Seeing the word
> "transaction" on their page made my heart sink to my boots!
>
> But yes, there are sufficient and large differences between their work
> and ours. They concentrate more on "smart transactions", attempting to
> optimize an installation where as we concentrate on managing
> transactions for atomicity (to implement things like rollback and
> transaction export/import)
I have to admit that I have got my own doubts (fuzzy right now) about
this transaction thing. The proposed model you are free to go up and
down the package levels seamlessly and the concept of 'rollback' is
making my head spin out numerous "What If" conditions.
Do you have a precedent from which you have borrowed these ideas or are
these original inventions ? Just curious ... :-)
> Package manager agnosticism is (an optional) byproduct in Corona, while
> its a major focus on their system.
Ok. I had a detailed look at Smart sometime back. They have some
excellent heuristics/algorithms in their code (Python too). If you plan
on GPL, you might like to borrow the good stuff that has been already done.
Cheers,
Ananth
_______________________________________________
ug-bosug mailing list
List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
List-Owner: mailto:ug-bosug-owner at opensolaris dot org
List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
|
|
|
|
|
Srichand Pendyala
srichand.pendyala@gm...
|
|
|
|
Re: Package management for BeleniX
Posted:
May 18, 2007 9:33 AM
in response to: ananth
|
|
|
|
On Fri, 2007-05-18 at 21:48 +0530, Ananth Shrinivas wrote:
> Hey Srichand,
> I have to admit that I have got my own doubts (fuzzy right now) about
> this transaction thing. The proposed model you are free to go up and
> down the package levels seamlessly and the concept of 'rollback' is
> making my head spin out numerous "What If" conditions.
>
> Do you have a precedent from which you have borrowed these ideas or are
> these original inventions ? Just curious ... :-)
All pure original ideas :)
Murphy's laws indicate we will run into a wall of some sort once we
start coding :)
To paraphrase Sir Humphrey Appleby "I forsee all sorts of unforseeable
problems!"
But could you list out your "What if" conditions, so we could have a
head start trying to solve them?
> > Package manager agnosticism is (an optional) byproduct in Corona, while
> > its a major focus on their system.
>
> Ok. I had a detailed look at Smart sometime back. They have some
> excellent heuristics/algorithms in their code (Python too). If you plan
> on GPL, you might like to borrow the good stuff that has been already done.
Wow! Yes, we're using the GPL. I will take a look at the code as soon as
I find sometime.
> Cheers,
> Ananth
Regards,
Srichand
_______________________________________________
ug-bosug mailing list
List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
List-Owner: mailto:ug-bosug-owner at opensolaris dot org
List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
|
|
|
|
|
Posts:
844
From:
INDIA
Registered:
2/10/06
|
|
|
|
Re: Package management for BeleniX
Posted:
May 22, 2007 12:23 AM
in response to: Srichand Pendyala
|
|
Srichand Pendyala <srichand dot pendyala at gmail dot com> wrote:
> Murphy's laws indicate we will run into a wall of some sort once we
> start coding :)
> To paraphrase Sir Humphrey Appleby "I forsee all sorts of unforseeable
> problems!"
>
Multiple repositories + Rollbacks is bound to unsettle anyone :-)
Add to this the goal of "No duplication of packages" makes it even
more tougher.
The above three things are the things I used to do often *manually*
with my ubuntu box when I did not have a dedicated net access.
- Download from multiple softwares in the form of
ubuntu/debian/fedora-core packages.
- Convert to .deb if necessary and manually install, on failure try to
fix/uninstall.
There used to be multiple points of failure - either within the
packages or some file/version/path dependency in the system (mostly
outside the influence of corona). I used to get things work for me but
the work flow was convoluted and something that did not yield to
automation.
>From those experiences I would say that the user would need to be ok
with the idea of his system or the softwares breaking now and then.
> > > Package manager agnosticism is (an optional) byproduct in Corona, while
> > > its a major focus on their system.
> >
All the great religious thinkers who abhorred the caste-systems/sects
pre-valent during their times ended up creating a set of followers
evolving to another caste/sect :-)
For now I would say,
[1] A discussion during one of the bosug sessions would "probably"
help settle on the starting point and possible way forward. (Moinak
has already called for one. Packaging/Builds will probably be the
primary topic).
[2] Getting a first working prototype with whatever reduced scope
would help. It would validate some of your assumptions and might
invalidating some others. The possibilities becomes much more clear.
-Shiv
PS: I know that there are a few points from your earlier mail that
needs a reply. I am leaving it for the session that I assume will
happen in bosug.
_______________________________________________
ug-bosug mailing list
List-Unsubscribe: mailto:ug-bosug-unsubscribe at opensolaris dot org
List-Owner: mailto:ug-bosug-owner at opensolaris dot org
List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
|
|
|
|
|
