[linux-elitists] Packaging, deps, and office suites

Karsten M. Self karsten@linuxmafia.com
Mon Oct 29 20:21:49 PDT 2007


on Mon, Oct 29, 2007 at 09:54:33PM -0500, Ruben Safir (ruben@mrbrklyn.com) wrote:
> > > > when their dependant package is removed.  
> > > 
> > > unless they shouldn't.  The whole package management concept is flawed.
> > 
> > Ah:  "It doesn't work."
> > 
> > Rant much?
> > 
> > Please see:
> > 
> >     http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
> > 
> 
> 
> Interesting but a flawed paper ;)  Frankly, too much is expected from the
> end user.  

You're an elitist, right?  We expect a lot from elitists.

> Most programs just crash without as much as a whimper.  They disapear like
> a champain bubble.  Go tell the user to giver you detailed information about
> how that happens.  Good luck.

Strace is your friend.  If you need network information, run wireshark.

In the case of most Debian install scripts (RH should be similar),
running bash -x on the postinst script and logging the output generally
works.  When providing IRC support, to non-elite users, I request a
pastebin of the output.  We get a pretty good success rate by this
method.
 
> > If you can describe one or more specific instances of undesired behavior
> > regarding package management behavior, please do.  Better yet, report
> > them as bugs.  Effectively.
> >
> 
> I don't want to turn this into a flame war, but packagemanagement is
> just flawed conceptually.  

Nice hand-wave.

What distro?  What specific problem?  How long ago?  Stable or unstable
release?

> It assumes a bunch of dependencies based on presumptions about the
> distros, naming conventions, and more.  

On distributions in which package management _works_, such things are
dictated by policy, e.g.:  "3.1 The package name", in Debian, which
includes "3.2 The version of a package".
 
> Instead of keeping tract of stupid naming conventions and files in a
> database, there already IS a database.  That database is called the
> FILE SYSTEM, an organized collection of inodes.

If you're interested in verifying the integrity of something other than
those raw inodes, a packaging system can be most beneficial.
 
> Programs should LOOK for their dependencies in a variety of rational
> locations.  It should know that if lib 1.0 works, then 1.2 should
> work, and be leery or 2.0 only if the programmer says so.

... and it's somehow easier to work directly with a diverse set of
upstream developers rather than put an intermediary set of package
maintainers who understand the current distro's policies, to
disintermediate?
 
> -- 

<15 lines of sig snipped>

aptitude install signify already


Peace.

-- 
Karsten M. Self <karsten@linuxmafia.com>        http://linuxmafia.com/~karsten
    Ceterum censeo, Caldera delenda est.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20071029/39241d20/attachment.pgp 


More information about the linux-elitists mailing list