MESSAGE
| DATE | 2007-02-18 |
| FROM | David Sugar
|
| SUBJECT | Re: [NYLXS - HANGOUT] [meissner@suse.de: [suse-security-announce] SUSE Security Announcement: samba remote denial of service (SUSE-SA:2007:016)]
|
Debian still uses an "installation" database of "installed" packages,
just like rpm does for rpm packages, freebsd does, etc. This is not a
question of how the metadata eventually arrives and is stored on your
system and maintained, but rather how packaging metadata is used to
construct the installation package from source.
In fact, for most cases I thing it matters little in the end. For
example, most people will not choose to build grep from source if they
do not need to, and there are not many compile time options to consider
:). However, for what is often the most important packages (such as the
Linux Kernel, or apache or Samba, for example), all packaging often
fails, because each of these have needs for far greater customization
and often different options than that which can be offered in the
"generic" distribution. Here is where it becomes important for uses,
whether building from source, or simply re-building a package for their
own needs and specific options that they can then distribute to multiple
machines, on whether or how badly packaging interferes with this
process.
What is good in BSD ports and packaging is that they support both models
seamlessly. You can take a package that is pre-built (say grep), and
install and maintain it along side a package that is "compiled" with
your own options and installed through the master make files found in
/usr/ports. At the same time, you could of course also work with a
package that has it's own make and build tools instead.
RPM based distro's could be made to work much like BSD does with
packages and ports, although to date nobody distributes a binary RPM
installed distribution that also includes the native "spec" files in an
equivilent of a /usr/ports directory to allow one to quickly modify and
rebuild a custom RPM package. Instead they often distribute SRPM's on
additional CD's rather than naked specs ready for use, which is really
what you do not want. However, in Debian, since you must start from
"Debianized" sources which contain packaging build instruction rather
than external metadata, it would be much harder to do the same there.
The key question I think for whether a packaging system and distro is
good or bad is in how readily it empower users, which is the key part
and purpose of what you say in the apache build tools. And a key part of
the education of users in living in the free world is for them to learn
and understand how they are empowered and are able to compile and modify
packages themselves rather than what they have been spoon-fed in
prepackaged software by any given distribution, regardless of the
packaging system used.
Ruben Safir wrote:
> On Sat, Feb 17, 2007 at 06:12:36PM -0500, David Sugar wrote:
> > I find specific and different issues in Debian. Unlike every other
> > packaging system out there (including BSD ports, gentoo, etc), they
> > choose to stick the packaging meta-data within the distribution package
> > (debianized source with a "debian" subdir in a modified source
> > distribution) rather than keep it seperate. This is a fundimental
> > design flaw.
> >
> > My other problem with Debian packaging is it remains overly complex.
> > While the original RPM faq explained within half a page how to create a
> > RPM that produces two or more output packages (something very common if
> > you are building a library which might include a seperate -devel package
> > with headers), the Debian maintainers document still says it is simply
> > too complicated to explain how to do this basic task or to explain
> > anything beyond the very simple example they do give and believe is
> > explainable which is valueless to any real packaging situation! This
> > alone speaks volumes to me about what is wrong in Debian packaging as an
> > architecture; if it is too complex to even explain something basic,
> > clearly it is designed wrong to begin with...
> >
>
> Being that I'm not producing any products for distribution like you do I've
> never dug very far into this. But if the debian packaging system is too complex
> to make it easy to role out then that would go a long way to explaining why
> so many fundementally broken debian packages exist and take forever to be
> fixed. In terms of where to put the metadata, one advantage I would think
> to a distributed mode would be that you wouldn't have a single point of
> corruption, such as an RPM database often has.
>
> Apache's compiling tools are somewhat unique. Like BSD ports, it uses
> compilation tools not only for compiling but also distribution AND are
> designed to give Apache operators real access to the code base to encourage
> module buidling, module fixing, and experimentation.
>
> Check this post from Tim Gales:
>
> "You are saying "Furthermore, Apache is designed to be
> expanded by modules making professional use of Apache OUTSIDE of any
> package management an essestial aspect of running the server."
>
> There is no design goal on the part of Apache developers
> like that.
>
> To paraphrase the developer's quote: The top design goal for
> the Apache server was to build a solid and dependable server
> (and we can infer that to mean one that would not need to be
> recompiled a lot for maintenance by either the users or
> their distributor/third party developers.)
>
> Notwithstanding the fact thatApache developers have good
> tools with which to build Apache, the developers clearly
> wanted users to *not* have to recompile from source to
> get diverse functionality."
>
>
> Did you ever read such crap? This guy is a flat-earther. He's plucking
> a few lines off the website to make the enourmous leap in logic to conclude
> that to argue that Apache developers designed the server to be understood
> within the logical construct of apt-get and for users to be dependent on third
> party modules rather than to be active development partners in making useful
> modules and core fixes in the core module base.
>
> In otherwords, this guinius has concluded that all the developement to break
> Apache from a singular binary construct to a completely modularized tool
> kit with the smoothest compiling and configuration tools of any project in
> existense is not to facilitate the coders abilty to debug code more efficiently
> through modulation and to facilitate creative expansive through a its well
> documented modular interface and API, but it was all so that some 3rd party
> like Microsoft or Debian can ramjet binary modules at you more smoothly.
>
> So of course, once this guinius makes this conclusion, its perfectly
> understandably why it is acceptable to recieve through a tech list calls for
> help which look like this:
>
> -------------------------------------------------------------------------
>
> Sorry to revive an old thread, but just as kind folks
> were helping out, we had a loss in the family and I
> dropped off the face of Nylug for a couple months.
>
>
> > On Wed, Nov 01, 2006 at 10:52:28AM -0500, Seth Rothenberg wrote:
> >> Greetings,
> >> I have a server running apache 1.3 and using
> >> VirtualDocumentRoot and PHP....and I want to
> >> do the same in Apache2.
>
> The debian mass hosting how-to is for apache 1.3
> I found another how-to for apache2, but either
> there's a step missing, or a step wasn't followed
> (by the silly guy at the keyboard).
>
>
> > Hi Seth,
> > what packages are installed wrt apache2 and php?
> > COLUMNS=200 dpkg -l |egrep "(apache)|(php)"|grep "ii"
>
> The good news is,
> I did a clean install, on a new server, and I at least got php
> working on the default domain. But still can't get virtual domains.
>
> cut -c-80 cmdout
> rothen at kx:~$ COLUMNS=200 dpkg -l |egrep "(apache)|(php)"|grep "ii"
> apache-utils 1.3.33-6sarge3 utility programs for webservers (transitiona
> apache2 2.2.3-3.2 Next generation, scalable, extendable web se
> apache2-doc 2.2.3-3.2 documentation for apache2
> apache2-mpm-prefork 2.2.3-3.2 Traditional model for Apache HTTPD 2.1
> apache2-utils 2.2.3-3.2 utility programs for webservers
> apache2.2-common 2.2.3-3.2 Next generation, scalable, extendable web se
> libapache2-mod-php4 4.4.4-8 server-side, HTML-embedded scripting languag
> php4-common 4.4.4-8 Common files for packages built from the php
>
> (Note, One person said "apt-get install apache2 libapache-mod-php4"
> but that doesn't seem to be everything I need to know :-)
>
> rothen at kx:/etc/apache2$ diff apache2.conf apache2.conf_original
>
> < LoadModule php4_module /usr/lib/apache2/modules/libphp4.so
> <
> <
> < AddType application/x-httpd-php .php .phtml .php3
> < AddType application/x-httpd-php-source .phps
> <
>
> The error message I get is this...
> NameVirtualHost *:0 has no VirtualHosts
>
> (and google gives me a nice run-around on that:-)
> (and of course, there are domains defined in
> sites-enabled and sites-available)
>
>
> I'd appreciate any pointers.
> BTW, it is my guess that a proper mass-hosting install
> has very little proprietary/security info in it,
> if diagnosis requires a look at the actual config,
> I can do that.
>
>
> BTW, isn't this something that everyone and their brother
> wants to do? It is STILL a pleasure adding domains
> to my apache 1.3 server. It's just time to move up.
> (remember that post about sharing costs with a friend?
> he really wants Apache2, and I really want mass hosting :-)
>
> ------------------------------------------------------
>
> And thats the kicker. He really thinks that running Apache with PHP and
> Virtual Hosts is ***hard***. My god. What was hard was understanding his
> damn question.
>
>
> > This is not to say RPM is a panecia either, and I agree the practical
> > and imperical experiances demonstrate there is a lot yet to be improved,
> > but at least it is easy enough for anyone to produce an RPM (or even an
> > ebuild, or a BSD port) , and because the packaging metadata is seperate,
> > it does not produce problems when either an upstream maintainer chooses
> > to offer their own packaging (in debian, maybe you would re-patch the
> > authors /debian directory? yuck) or to maintain their own varient of
> > specific packages from that of a distribution without having to produce
> > their own varient of impure source distributions...
> >
>
>
> Ruben
>
> --
> http://www.mrbrklyn.com - Interesting Stuff
> http://www.nylxs.com - Leadership Development in Free Software
>
> So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998
>
> http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
>
> "Yeah - I write Free Software...so SUE ME"
>
> "The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."
>
> "> I'm an engineer. I choose the best tool for the job, politics be damned.<
> You must be a stupid engineer then, because politcs and technology have been attacted at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."
|
|
