[belenix-discuss] Proposal: use rpm5 package format and the smart package manager
Sriram Narayanan
usage experience:
- easy to use smart package manager (using yum and rpm is optional)
- the familiar rpm format for the actual package files
- support from the rpm5 and the smart package manager community
Reasons for rpm5:
- based wide spread use on desktop as well as server grade Linux based
distros such as RHEL, rpm works well and meets our needs of a good
modern package system
- I have managed to build rpm5 and have requested Jeff Johnson, the
present rpm5 maintainer and developer, to integrate two fixes needed
to build rpm5 on the opensolaris platform
- the current maintainers of rpm5 have given us a go ahead on bundling
rpm5 with Belenix [1]
- rpm5 is actively maintained [2]
- it uses modern compression systems and libraries [3]
- it is used by other distributions as well, who don't mind sharing
their learning with us [4]
Pending investigations:
1. Compatibiity with pkg-build spec files
We could potentially directly consume all the pkg-build specific spec
files in case we want to attempt source builds. I'm fairly confident
this should work, and I will be working on a test case. This may very
well be needed in case we use gcc to build KDE packages (necessary in
case we don't use hajma's SS12 built KDE IPS packages).
2. Direct import of IPS files into rpm5 files.
In case we decide to convert openindiana packages into rpm packages,
we'll need something like alien which would read IPS and generate rpm
files. This needs some investigation.
I also propose that we use the smart package manager
(http://www.labix.org/smart/):
- There are a number of dependency resolution issues that the smart
package manager has solved [5]
- There are a number of interesting features [6]
- There is wide spread adoption today of this tool by Ubuntu, Fedora,
and Suse, and other efforts such as unitylinux.
- smart provides many of the convenient command line parameters as does apt-get
- the smart community members are OK with us bundling smart within Belenix [7]
- Here is the smart package manager FAQ [8]
Unfortunate reasons for not being able to use .deb files (the dpkg format)
- At this time, the debian-legal community is still largely against of
bundling Nexenta's zfs-aware dpkg with a distro. [9]
- We don't have either the mental energy, the time, of the legal
awareness to go argue with debian-legal
- we don't want to get into disagreements with other open source and
free software communities.
Some thoughts on questions about apt-get
1. apt-get is great !
apt-get is a front for dpkg. The convenience of apt-get is matched by
the smart package manager.
2. apt-get gives me everything
Actually, apt-get merely queries a catalog of software, and let's us
install, upgrade and remove software. A rich collection of software
packages is something that the overall openindiana community can work
together on (with Belenix being part of that community).
3. apt-get is easy to use
Well, rpm has similar commands, and so does smart. Our overall
emphasis should be on using the smart package manager which will
consume rpm files underneath.
Links:
[1] http://www.mail-archive.com/rpm-...@rpm5.org/msg00519.html
[2] http://rpm5.org/files/rpm/rpm-5.3/SNAPSHOT/
[3] http://rpm5.org/cvs/fileview?f=rpm/INSTALL&v=2.122.2.4
[4] http://www.mail-archive.com/rpm-...@rpm5.org/msg00521.html
[5] http://zorked.net/smart/doc/README.html#study-cases
[6] http://labix.org/smart/features
[7] http://lists.labix.org/pipermail/smart-labix.org/2010-September/004099.html
[8] http://www.labix.org/smart/faq
[9] http://lists.debian.org/debian-legal/2010/09/msg00001.html
-- Sriram
--
Belenix: www.belenix.org
_______________________________________________
belenix-discuss mailing list
http://mail.opensolaris.org/mailman/listinfo/belenix-discuss
http://groups.google.com/group/belenix-discuss
USM Bish
> I want to propose that we move to rpm5 to give the user the
> following usage experience:
>
> - easy to use smart package manager (using yum and rpm is
> optional)
>
> - the familiar rpm format for the actual package files
>
> - support from the rpm5 and the smart package manager
> community
>
> Reasons for rpm5:
>
> - based wide spread use on desktop as well as server grade
> Linux based distros such as RHEL, rpm works well and meets
> our needs of a good modern package system
>
> - I have managed to build rpm5 and have requested Jeff
> Johnson, the present rpm5 maintainer and developer, to
> integrate two fixes needed to build rpm5 on the opensolaris
> platform
>
> - the current maintainers of rpm5 have given us a go ahead
> on bundling rpm5 with Belenix [1]
>
> - rpm5 is actively maintained [2]
>
> - it uses modern compression systems and libraries [3]
>
> - it is used by other distributions as well, who don't mind
> sharing their learning with us [4]
>
I really do not know, if you really need a "binary package"
based approach. The issue is the variability of hardware use
here. I have nothing against "rpm" or "dpkg" based approach,
but then, at the end of the day, Belenix would become "Yet
Another Distro" ! Since the userland s/w is same for all *nix
based OSs, nobody would appreciate the difference.
I found nothing wrong with the "specs" based system which
Moinak had used for the initial belenix development. This can
be easily extended to a source based distribution system. My
preference would always be for a source based technology,
rather than pre-compiled binary downloads. Anything compiled
on your box always works !
Please study the *BSD ports systems. it would be the easiest
to implement on existing "specs" platform. It would also
reduce server requirements for storing various versions of
binaries.
For those, who have not used FreeBSD/ OpenBSD etc, "port" is
a technology used to install from source. Each Port is
a collection of scripts that when executed, automatically
download source of softwares from the Internet, patches,
configures if necessary, compiles and install it. Any
dependencies on other applications or libraries a port may
have are also installed for the user.
Like binary packages and ports understand dependencies.
Suppose you want to install an application that depends
on a specific library being installed, the ports system
automatically installs the library first.
Each port, or software package, is maintained by a “port
maintainer”, an individual who is responsible for staying
current with the latest software developments. Anyone is
welcome to become a port maintainer by contributing their
favourite piece of software to the collection. One may also
choose to adopt and maintain an existing port that has no
maintainer-ship.
This brings in better contribution and participation from the
community. You would notice, binary "packages" are invariably
the handiwork of a core group, thus creating an artificial
divisions of "developers" and "users".
Having things this way, would reduce the work of the core
group at developing a base install with minimal X with a full
gcc based development environment and networking support. The
"base" distro would be smaller, and "meaner", but more solid.
Now that Oracle has pulled the plug on OpenSolaris, a larger
community support is needed if any fork of the old OpenSolaris
base is to continue.
Just another view,
Bish
Moinak Ghosh
> On Fri, Nov 5, 2010 at 9:07 PM, Sriram Narayanan <sri...@belenix.org> wrote:
>> I want to propose that we move to rpm5 to give the user the
>> following usage experience:
>>
>
> I really do not know, if you really need a "binary package"
> based approach. The issue is the variability of hardware use
> here. I have nothing against "rpm" or "dpkg" based approach,
> but then, at the end of the day, Belenix would become "Yet
> Another Distro" ! Since the userland s/w is same for all *nix
> based OSs, nobody would appreciate the difference.
>
> I found nothing wrong with the "specs" based system which
> Moinak had used for the initial belenix development. This can
> be easily extended to a source based distribution system. My
> preference would always be for a source based technology,
> rather than pre-compiled binary downloads. Anything compiled
> on your box always works !
>
Yes a Gentoo like source based system appears nice and
is attractive to a bunch of people. However from my experience
most (me included) do not want their desktops/laptops doing
long-running builds the moment they try to install a package.
It becomes a worst-case scenario when you are doing a full
upgrade, or when you are trying to install big software bundles
like say Koffice, Firefox etc. Your laptop can potentially spend
a week compiling stuff, if you can keep it continuously on for
that long without overheating or battery draining if you are on
the move.
At the risk of starting a controversy: How popular is Gentoo today ?
In addition we plan to work with one standard codebase maintained
by the common community. Better cooperation and sharing of
effort. It is simply impossible for a few folks working on BeleniX to
maintain a parallel build system and parallel source base and
stacks of thousands of FOSS. Rather than fragmenting efforts we
stand to gain by cooperating in a single OpenIndiana community.
In addition the so called consolidations or multiple source bases
from which a typical OpenSolaris distro is built are diverse with
divergent build systems. It is quite a task to cohesively orchestrate
among these diverse systems.
Having said this we definitely want source build to be a reality for
those who want to experiment. It may even be an excellent way
to build and install Multimedia related software with machine
specific optimizations. Having a source build install is also related
to a future effort within the OpenIndiana community to unify build
systems to a common system, logically spec files as of now.
> Please study the *BSD ports systems. it would be the easiest
> to implement on existing "specs" platform. It would also
> reduce server requirements for storing various versions of
> binaries.
>
Yes ports handles additional layered software, not the core
system. Disk space goes cheaper and cheaper so storage is
not an issue :)
Usability and end-experience are primary motives here.
> For those, who have not used FreeBSD/ OpenBSD etc, "port" is
> a technology used to install from source. Each Port is
> a collection of scripts that when executed, automatically
> download source of softwares from the Internet, patches,
> configures if necessary, compiles and install it. Any
> dependencies on other applications or libraries a port may
> have are also installed for the user.
>
> Like binary packages and ports understand dependencies.
> Suppose you want to install an application that depends
> on a specific library being installed, the ports system
> automatically installs the library first.
>
> Each port, or software package, is maintained by a “port
> maintainer”, an individual who is responsible for staying
> current with the latest software developments. Anyone is
> welcome to become a port maintainer by contributing their
> favourite piece of software to the collection. One may also
> choose to adopt and maintain an existing port that has no
> maintainer-ship.
>
> This brings in better contribution and participation from the
> community. You would notice, binary "packages" are invariably
> the handiwork of a core group, thus creating an artificial
> divisions of "developers" and "users".
>
The same binary packages are built from spec files or maybe
makefiles, however each package gets an identified maintainer
to avoid any artificial divisions. Fedora does it that way and
distributes binary packages. The OpenIndiana folks are already
working to standardize processes in this regard.
> Having things this way, would reduce the work of the core
> group at developing a base install with minimal X with a full
> gcc based development environment and networking support. The
> "base" distro would be smaller, and "meaner", but more solid.
>
This is possible even with binary packages if the right level
of package granularity is maintained. In the OpenSolaris world
there are bigger issues than source vs binary packaging that
makes a mini distro more challenging that it should be. One
of those is the big monolothic packages that come out of the
core OS build.
> Now that Oracle has pulled the plug on OpenSolaris, a larger
> community support is needed if any fork of the old OpenSolaris
> base is to continue.
>
Yes, this is already happening around Illumos and OpenIndiana
efforts and we should gather around those and contribute to the
common goal.
Regards,
Moinak.
--
================================
http://www.belenix.org/
http://moinakg.wordpress.com/
Sriram Narayanan
On Tue, Nov 9, 2010 at 7:51 PM, Moinak Ghosh <moi...@belenix.org> wrote:
> On Sat, Nov 6, 2010 at 8:50 PM, USM Bish <bi...@airtelmail.in> wrote:
>>
>> I really do not know, if you really need a "binary package"
>> based approach. The issue is the variability of hardware use
>> here. I have nothing against "rpm" or "dpkg" based approach,
>> but then, at the end of the day, Belenix would become "Yet
>> Another Distro" ! Since the userland s/w is same for all *nix
>> based OSs, nobody would appreciate the difference.
>>
Yes, we could indeed become Yet Another Distro. Given that the core
team often has little time to stay abreast of package versions, it
becomes useful for us to use the OpenIndiana team's efforts, to
contribute spec file fixes there, and to focus on other
differentiating factors such as installers, package managers, system
tools, moving to more bleeding edge kernels from illumos as compared
to OpenIndiana, etc.
>> I found nothing wrong with the "specs" based system which
>> Moinak had used for the initial belenix development. This can
>> be easily extended to a source based distribution system. My
>> preference would always be for a source based technology,
>> rather than pre-compiled binary downloads. Anything compiled
>> on your box always works !
>>
We'll continue to use spec files where needed. The spec files that
we've been using so far, are spec files that have all the elemets that
rpm supports as well as some elements that have been specific to the
pkgbuild build system.
Moinak has proposed that we treat OpenIndiana as our upstream, import
binaries from within the IPS files into RPM files, and then use those
RPM files.
<snip/>
>
> Having said this we definitely want source build to be a reality for
> those who want to experiment. It may even be an excellent way
> to build and install Multimedia related software with machine
> specific optimizations. Having a source build install is also related
> to a future effort within the OpenIndiana community to unify build
> systems to a common system, logically spec files as of now.
>
In fact, with the spec files and the rpmbuild build in place, one
could consider modifying ports or portage to pull in specs and
rpmbuild into the destination folders.
<snip/>
>> Now that Oracle has pulled the plug on OpenSolaris, a larger
>> community support is needed if any fork of the old OpenSolaris
>> base is to continue.
>>
>
> Yes, this is already happening around Illumos and OpenIndiana
> efforts and we should gather around those and contribute to the
> common goal.
>
Based on the outcome of this discussion, we'll be talking about the
Belenix goals on the OpenIndiana lists.
> Regards,
> Moinak.
> --
-- Sriram