Bart Smaalders wrote:
> Jason Zhao wrote:
>> By adding this, it will be convenient for administrator. Especially, when
>> there is some packages were added by "pkgadd", but there is no index for
>> these packages in /var/pkg, and most of important the administrator know
>> what he needs to do and what he is doing. It will be easy to only add one
>> single package, otherwise, it will be time consuming to add them all.
>  >
>
>> Anyway, it brings flexible works.
>
> So does using a binary editor on your raw disk to modify your 
> filesystem.  It still doesn't mean it's a good idea.

But it definitely doesn't imply it is a bad idea.
If I know what/why/how, I should be allowed to do this.
I think that following statement better explains
the philosophy I prefer as far as taking
restrictive versus liberal approach is concerned:

"/UNIX was not designed to stop its users from doing stupid things,
as that would also stop them from doing clever things./"


>
> Example:
>
>       Package A has a hard link to a file in package B, and thus has a
>       dependency on pkg B.

In this particular case, my feeling is that A should deliver both
(file as well as hard link). But to be honest, I am not very
familiar with rules how packages should be put together as far
as dependencies are concerned. Is there any document which covers
this kind of things for IPS and what the mandatory as well as
recommended rules are ?

>
>       How do I install package A without package B?
>
> Installing packages without their dependencies being present means the
> package is broken.  Arbitrary things can and will happen as a result,
> including placing critical system services in maintenance mode.

Agreed and I am ready to take that risk.

>   No one
> tests their packages and services to discover the behavior when
> arbitrary dependencies have been removed.

Understood and I will blame only myself when I break my system
by doing this.

>
> The function of the packaging system to is construct working images, 
> where "working" is defined as packages that are installed as specified
> by their publisher.

I agree this perfectly fits 'default behavior' scenario.
But I am not sure this is the only one which should be
available, since I am still not convinced it covers needs
of all (or even most) potential consumers.

For instance, let's assume I want to create my own tiny
Solaris distribution (e.g. to be deployed on some kind
of embedded system) using Distro Constructor. In this case,
I want to have complete control over what is to pulled into
my proto area and present in final image by explicitly
specifying all packages I am interested in.

e.g. why should I be enforced to install SUNWpython-cherrypy
SUNWipkg depends on, if I know I will be using pkg only as a
client ?

I can think about another scenario. Let's assume that package
A depends on functionality delivered by package B.
I decide that instead of delivering that functionality by
installing B from IPS repo, I will rather compile latest
version from sources (e.g. because it contains some additional
feature I would like to take advantage of).
How this scenario fits in broader IPS packaging philosophy ?

Jan

_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to