C. wrote:
5) "a secure package manager without any arbitrary post/pre-install
scripts"
Ok.. so wait a second.. Let's first of all define "secure" because last
I checked the IPS authorities aren't signed.. Are they? You're only
They are not currently, but this is definitely planned functionality.
looking at it from one angle.. If a package is signed and trusted by
the authority then the script isn't arbitrary. It was designed and
created with a sole purpose. If it *is* arbitrary I don't think I'd
There are a significant number of packages from third-party vendors and
from Sun itself that were "created for a sole purpose" that often don't
work right because of incorrect assumptions made in the pre/post install
scripts. So, arbitrary in the sense that it made "arbitrary
assumptions" would be correct.
backing it. When the IPS repo is handling 10k+ unique pieces of
software lets talk. Those scripts are there to add *robustness* to the
The other day, you threw out the number of 2,000 unique pieces of
software. Well, I have good news for you, if you combine the primary
opensolaris.org repository (about 1800 unique packages), and the contrib
repository (about 11,505 unique packages), you'll easily be over that
10k+ unique number you're talking about. And you'll find that the
pkg(5) system can manage it.
think some features are *good*.. Does removing pre/post scripts warrant
a new package manager.. Bluntly put.. No.. it sure hell doesn't.. This
is why people who have a clue are so pissed off.. Because good people
have been fired before, but there's still this rogue team wasting cycles
on stuff which could ultimately be spent elsewhere.. So forgive me and
other when we are a bit rude and aggressive...</rant>
I'm sorry if you think this is a "rogue team"; but it isn't.
The pkg(5) system was not designed solely to eliminate scripting,
Rather, it was designed to create a packaging system that fully
integrated with OpenSolaris and took advantage of its significant,
unique technologies (such as ZFS) and satisfied the needs of a target
audience.
As you point out, many packaging systems have been around for a
significant number of years. However, what you didn't point out is how
stagnant the design of these systems has been, and how they've all
stayed rather generic instead of trying to uniquely innovate for a given
platform.
7) is very easy to use...
ok. you got me there... they were able to make a cli interface that is
at least comparable to things which have been around for 15 years.. :)
In some areas yes, the pkg(5) system is merely comparable to other
packaging systems.
However, in other areas, such as the pkg(5) search interface,
(especially as of build 110) it is significantly advanced compared to
that provided by deb, rpm, or other systems. It also offers a remote
search interface that none of those other systems have, allowing users
to search for packages without downloading large metadata blobs from
package repositories.
8) upgrades the whole system at once, versus just the packages, which
ensures you won't have any conflicts
...
b) because of the way manifests are created from entire packages just
like any normal or sane packaging system you're still just as likely to
have unresolved dependencies or blockers. (I don't know for certain a
missing file can't pull for *any* manifest even one which provides the
same package at a different version)
The way dependencies are declared in IPS manifests is not different (as
far as I remember) from rpm, deb or other popular packaging formats.
So, I fail to see the issue with that.
The existing dependency resolution mechanism in pkg(5) is due to be
replaced soon with a SAT-solver based mechanism.
c) if you argue that is saves bandwidth.. I'll argue that it has
delayed being able to easily establish a mirroring system, it forces a
It is very easy to create a mirror, and this functionality has been
there for several months now.
custom daemon, there's no on-disk format (maybe this was resolve
To provide the sort of rich, remote functionality that our packaging
server provides, you have to have custom software of some sort running
on the remote package depot server.
The on-disk format was seen as less important than other, significant
pieces of functionality and is planned to be implemented at a later date.
10) I've been using IPS since its inception, for how long have you been
using it ?
This is you just trying to discredit what I've said. As you can see
above I think you're just an end user that isn't really clear on what's
going on or slightly mistaken in some points. *If* you have used IPS
for as long as you say you have I think you'd be a bit more empathetic
to certain facts. Did it allow you to cleanly migrate from the original
05/08 release until today? I'm sure at some point you've had to do a
fresh install or skipped many updates. There's been a number of bugs
since the original version.
I have a system that has been continuously upgraded since build 86 using
IPS (it's also one of the tests that is run from time to time to ensure
this works still).
You should also be able to upgrade directly from build 86 to build 110.
However, while the packaging systems itself shouldn't limit you from
doing that, other components of the system may cause issues.
Yet, Lurie does have a point here, you appear to have spent very little
time using IPS, and despite repeated invitations to provide specific,
constructive feedback, many of us are still waiting for it.
Constructive, useful feedback that can be used to help guide design and
implementation is useful for any software project.
If pkg(5) is merely "reinventing the wheel" as you say, and is merely
being produced by a "rogue team", then you have nothing to worry about.
Your fellow wheelwright,
-Shawn
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
