Tobias Gasser wrote:
>> A good package manager is, IMO, a necessity.
> NO!!!!
>
>
> i'll explain why i NEVER will use any package-manager:
The choices you make are of course your own. I would
not presume to tell you what you should do for your
own machine. I stated what I consider to be necessary
for my machines, and my machines only. That's why I
put the qualifier "IMO" into that statement.
I'm a little surprised at the vehemence of your statement.
Why are you so excited by my opinion which applies only to
the machines I own that you used four exclamation marks?
> have a look at the configure options with php5:
[...]
> which version do you declare the one and only to be used for the
> package-management??
I don't declare any particular version to be the one and only to be used
for package management.
I have used both of the terms
version control (which is what you allude to here)
package management (which is related, but an independent
concept)
You seem to be conflating them.
> with (b)lfs i have full control on what is installed on a system. i
With a proper version control manager, package manager, and build
control and integration system, you would have complete control
over every full system you built.
> really dislike packages like "php5" + "php-mysql" + "php-pgsql" +
> "php-whatever-you-wish" (and each one again with -devel). i just compile
> php with all the options i need on a particular machine.
ISTM that you have relatively little contact with
reasonable version control, package management, and
build control systems. It shouldn't even be necessary
to compile or build the image(s) necessary for a given
machine on a machine of the same architecture, let
alone for it to be the same machine. Most of the work
I've done with such types of build systems was compiling
for an OS (embedded proprietary RTOS) and machine
architecture (microcontroller) which were both different
from those on the development machine (often Solaris
on a Sparc). In fact, often multiple targets with different
machine architectures were often specified, and the software
required to run properly on all of them, and multiple
target builds might be required for a single release
of a subsytem (package).
What is necessary is a full and correct
specification of what a given target build requires,
and some tools which know how to interpret that
specification and create the necessary packages, and
integrate them into a deliverable product which is guaranteed to
meet the specifications.
Once the requirements for a given build have been specified,
the build should not require further intervention, other
than to command it to be done.[*] The result of the build
should be all components necessary for the target to boot
and run. One of the "packages" may be an installer which
will update a target to the latest release level. With a
good front end, one can use some relatively easy to use
tools to generate the specification of the target.
Of course, creation of such a collection of tools is a
significant effort, as is maintenance of it, as well
as the maintenance of the specifications, though those
should be relatively static by comparison with the
point releases of the components comprising the deliverable.
[...]
> greetings from switzerland
Greetings from the U.S.A.
[*] Of course, test is still required to verify that the functional
and performance requirements are actually met, on the target, that
is, to verify proper operation. I mean that the /build/ is guaranteed
to meet its specifications, not that the built image meets is
requirements. That's another matter altogether.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
