gnu-system-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU System Explanation


From: Alfred M\. Szmidt
Subject: Re: GNU System Explanation
Date: Sun, 12 Feb 2006 12:21:25 +0100

   >> Can someone please give me a concise explanation of what the
   >> intended goals are here?
   >
   >The goal is to make package installation and removal as easy as cp and rm.

   This is my point.  I don't think it can be unless you ignore things like 
   dependencies.

If you use ln/cp/mv/rm directly, then you loose dependency tracking
yes.  But often, when you wish to install your own tweaked programs,
you really don't care about such things, and simply wish to install a
program that makes it easy for you to remove at a later stage.

   >> I understand that you want packages isolation in /packages, but
   >> why?  Managing multiple versions of a package could potentially
   >> become a headache I believe.
   >
   >With current state yes. But that problem will be solved.

   How?

By giving a priority to a specific package maybe; say the first
package after sorting the list of packages in /stow by lexical
ordering.

   >> For example:  I have /packages/foo-1.1/bin/foo  and /lib/libfoo.  Then I
   >> install foo-1.2 which has /packages/foo-1.2/bin/foo and /lib/libfoo,
   >> foo-1.1 becomes pretty much unusable anyway, does it not?
   >
   >Why do you need both foo-1.1 and foo-1.2?

   I would ask the same question.  If this is not the goal, what is the 
   advantage of "package isolation"?

Easy removal for one.  But being able to install foo-1.1 and foo-1.2
should be possible in the future.  We could make stowfs default to a
specific package, and then you could ask for a specific version.

   >I didn't quite understand your example. Dependencies will be implemented
   >somehow.

   This is my fundamental question.  If there are decent workable package 
   management systems out there, why not use them rather than trying to 
   re-invent the wheel?

You are confusing two issues.  The actual package format, and the way
to track dependencies.  The later can probobly be taken from some
other part in large chunks.  The way packages are formated must be in
such a way that you can simply extract them, and put them some where.
dpkg, rpm, etc, do not allow for this due to the amount of meta-data
they store, and how they store it.  For example, a dpkg package is
really an ar archive, which contains two or three tar.gz archives,
which in turn contain data and meta-data. Such a format is totally
unsuitable for our needs.

   I like dpkg/apt, I just hear from lots of "GNU" folks that it
   sucks.

I'd be interested in knowing who says that apt-get sucks.  apt-get is
wonderful, and we _must_ have such a front-end to be sane.  But
apt-get is just that, a front-end.  You are confusing two issues here,
the underlying mechanism for how packages work, and the front-ends
that are built on top of that.  You as a user really never ever come
in touch with dpkg!

Cheers.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]