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

Re: [users] Re: Time to fight for our beloved DEB format!

On 30 Jun 2001 at 16:43 (-0700), Sean 'Shaleh' Perry wrote:
| > IMNSHO the LSB seriously erred on this, the .deb format makes far more
| > sense as a baseline package format standard then rpm for the simple
| > reason that the .deb format isn't really a format, its just an ar
| > archive with gzipped tarballs!  those formats are nearly the oldest
| > *real* standards as you can get with *nix.  .deb can be extracted on
| > ANY OS, even an old decrepid proprietary UNIX host.  a baseline
| > standard package format should be something that does not require
| > special tools to deal with, tar.gz and .deb meet that criteria, rpm
| > does not.  you can for example extract a .deb on a stock slackware
| > system, not true of rpm.  (unless slackware started including rpm in
| > the base since i last looked..)
| > 
| I agree with you 100% -- except you left out a few points which explain how
| they made the decision.
| a) there are 3 established dists that use rpm plus numerous small ones
| b) most proprietary software, if released for linux, is released as rpms already
| c) tied to b) companies like to deal with companies, RH provides this
| d) as part of a) there are like 3 (maybe as high as 6 or more) to 1 more people
| using rpm than deb
| yes we all dislike rpm for our own reasons.  however the decision that the lsb
| made does make sense.  The lsb is not meant to help you or me.  It is meant to
| help companies support linux.  companies understand RH and rpm better than they
| do debian. 

Proposal: Let's write a book about apt/dpkg. 

Seriously, a document like this could do wonders for selling debian 
for use in the heavy duty role it is bred to do. I consult with a large
firm that uses linux on its intranet. They purchase every book about
linux. Their employees absorb the books. The company's only open
source platform is linux -- Redhat. I'm not saying this is bad, it does
suit their needs well; they can feel comfortable knowing that their
employees have sufficient material to learn about this 'unsupported'
software running critical parts of their internal network. Yes, I'm 
aware that Redhat (and other firms) will sell support for linux, but
in the end those support firms cannot (AFAIK) be held financially 
accountable for the suitability and operation of the software in the 
environment, so the company does the next best thing it can, puts the
responsibility on the IT department, who is generally willing to 
toe the line, but Corporate feels better knowing the software is
documented, so they buy books, about Redhat.

Here we go. help me fill in the blanks.

1) Introduction:  apt in action
     (walk the reader through some of the use cases for debian's apt
      system. i.e.: doing a simple incremental upgrade of a debian 
      system; doing a dist-upgrade to a system; writing a cron job
      to update a server on a regular basis (security updates);
      setting up a local repo for distributing custom apps to a 
      network of debian systems, which uses the same cron facility
      previously mentioned. This chapter should be an entirely 
      enjoyable and leisurely read. Basic storytelling.

( the rest of the book should detail the example the user was exposed
  to in the Introduction.) 

2) Using apt:
    a) explain sources.list and detailed example of adding a new
    b) updating && upgrading
    c) searching
    d) installing
    e) detailed explanation of sources.list
    f) explain the apt config files
    n) other stuff ...

3) Introduction to dpkg:
    a) explain relationship of dpkg to apt
    b) example of creating debian packages
      1) modifying existing packages to suit environment
      2) creating simple package comprised of one file inside
      2) creating from source archive
    b) explain layout of apt archives
    c) explain a source package
    c) explain Packages and Source file
    n) other stuff ...

4) Advanced Use Examples:
    a) setting up local debian mirror
    b) setting up local archive
    c) adding local file to replace same package in mirror
    n) other examples

5) Appendix: ( will be very large :)
    apt documentation
    dpkg documentation
    debian constitution
    (other debian structural documents, licenses, etc.)
    LSB Documentation
    (other debian documentation)

Help out. pick a part to fill in. Send me an email. Remember that this
should most of all be stress-free reading until the Advanced Use 
chapter, then the user is fair game. Give all the details you can,
even if it pushes the lightweight reader away. Appendix should be
appropriate only for developers, and may include more examples of 
using apt and dpkg.

I certainly don't have the time to write a thing like this on my
own, but would be more that willing to do my part as long as I could
if others expressed a similar interest in putting together a book
on these subjects.


Reply to: