Re: Differences of Debian vs. the Other Guys
Manoj == Manoj Srivastava [EMAIL PROTECTED] writes: Manoj iii) It forces you to use fakeroot or sudo or super or Manoj be root to Manoj create a kernel image .deb file (this is not as Manoj bad as it used to be before fakeroot) I question the wisdom of installing a kernel built by someone you don't trust as `root'. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Differences of Debian vs. the Other Guys
[EMAIL PROTECTED] (Karl M. Hegbloom) writes: Manoj == Manoj Srivastava [EMAIL PROTECTED] writes: Manoj iii) It forces you to use fakeroot or sudo or super or Manoj be root to Manoj create a kernel image .deb file (this is not as Manoj bad as it used to be before fakeroot) I question the wisdom of installing a kernel built by someone you don't trust as `root'. Who said anything about installing? Building and installing kernels are different issues, and can be done on radically separate and different machines. -- James ~Yawn And Walk North~ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Differences of Debian vs. the Other Guys
Gosh!!! This really was good Manoj. I really enjoyed reading this technical dissertation on the magic of Debian. Can't this be placed somewhere in www.debian.org? E.- Manoj Srivastava [EMAIL PROTECTED] wrote: Hi, Well, there are a number of things, but the following are important (in no particular order) -- Eloy A. Paris Information Technology Department Rockwell Automation Venezuela Telephone: +58-2-9432311 Fax: +58-2-9431645 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Differences of Debian vs. the Other Guys
Manoj hit all the major points, and about every other point under the sun :) But I would like to expand on what I think are the key differences. 1) It's a distributed volunteer based system with lots of contributors. This sometimes leads to long arguments, but it means that policies must be thrashed out and specified precisely. It means that systems must have well designed modular interfaces to make it possible for packages to be maintained effectively by different maintainers. It also means we have a huge number of packages, all of which are held to the same standards and using the same bugtracking system. No directories of use at your own risk contributions. 2) Debian has a very strong commitment to Free Software. Everything in the distribution proper is supposed to be Free Software. Non-free software is in a separate section which isn't included on most CDs. Users of Debian can be sure they have the freedom to use and modify any component of the distribution without breaking restrictive licenses. I've included our Social Contract and the Debian Free Software Guidelines below to help make this clearer. Debian GNU/Linux Social Contract We are Software In The Public Interest, producers of the Debian GNU/Linux system. This is the social contract we offer to the free software community. Social Contract with the Free Software Community 1. Debian Will Remain 100% Free Software We promise to keep the Debian GNU/Linux Distribution entirely free software. As there are many definitions of free software, we include the guidelines we use to determine if software is free below. We will support our users who develop and run non-free software on Debian, but we will never make the system depend on an item of non-free software. 2. We Will Give Back to the Free Software Community When we write new components of the Debian system, we will license them as free software. We will make the best system we can, so that free software will be widely distributed and used. We will feed back bug-fixes, improvements, user requests, etc. to the upstream authors of software included in our system. 3. We Won't Hide Problems We will keep our entire bug-report database open for public view at all times. Reports that users file on-line will immediately become visible to others. 4. Our Priorities are Our Users and Free Software We will be guided by the needs of our users and the free-software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environment. We won't object to commercial software that is intended to run on Debian systems, and we'll allow others to create value-added distributions containing both Debian and commercial software, without any fee from us. To support these goals, we will provide an integrated system of high-quality, 100% free software, with no legal restrictions that would prevent these kinds of use. 5. Programs That Don't Meet Our Free-Software Standards We acknowledge that some of our users require the use of programs that don't conform to the Debian Free Software Guidelines. We have created contrib and non-free areas in our FTP archive for this software. The software in these directories is not part of the Debian system, although it has been configured for use with Debian. We encourage CD manufacturers to read the licenses of software packages in these directories and determine if they can distribute that software on their CDs. Thus, although non-free software isn't a part of Debian, we support its use, and we provide infrastructure (such as our bug-tracking system and mailing lists) for non-free software packages. The Debian Free Software Guidelines 1. Free Redistribution The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale. 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. 3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. 4. Integrity of The Author's Source Code The license may restrict source-code from being distributed in modified form _only if the license allows the distribution of patch files with the source code for the purpose of modifying the
Re: Differences of Debian vs. the Other Guys
On 02-Jun-1998, Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] wrote: I'm currently writting an article for Linux Actual (an spanish magazine on Linux) about the Debian Packaging System (more on the .deb format than other policies) and I would like to make the BIG question, considering there is a lot of discussion about LSB. start big question --- What are the main differences/advantages/disadvantages of Debian's Packaging System vs The Other Guys (tm) ? --- end big question --- Manoj addressed most of the big differences in his mail. One that he missed (or glossed over) is the difference in generation of packages. dpkg encourages (practically enforces) building a package in a working directory, installing files to a temporary directory, and packaging from that directory. e.g.configure --prefix ./debian/tmp make make install package up ./debian/tmp is what the debian/rules file says. rpm encourages (practically enforces) building a package, installing it in /usr, then listing all the files that were just installed. e.g.configure --prefix /usr make make install package up all listed files This is very error prone. Three big problems can occur: 1. Maintainer lists files that were on their system, but were not generated by the source archive. This means that the source RPM cannot generate the binary RPM on anyone elses system (except perhaps if they install the binary first, then create the package -- but it's a risk, and might eventually lead to packages that cannot be effectively maintained). 2. Maintainer fails to list files that were installed. Package works fine for them, because they installed the files using make install, so all files are present. Package doesn't work for anyone else. 3. Package maintainers machines get full of junk files, because they are only *producing* packages for people, their own system is used to install packages. When I discovered this is how rpm works, I was very disappointed. dpkg has gone the extra mile, and done things properly, despite being a bit more difficult to implement. dpkg makes packaging quicker, cleaner, and less error-prone. Add to this the lovely cvs-buildpackage (automatically builds packages out of CVS archives), and dpkg is a formidable packaging system. .deb vs .rpm isn't much competition -- they are both functionally equivalent at this level (so are .tar.gz or a .zip files really). But when you look at the tools and process used to create a .deb versus a .rpm, I think RPM needs some work. But chances are there are things I don't know about RPM -- I looked at it a while ago. Good luck on your article. -- Tyson Dowd # So I asked Sarah: what's the serial number on # your computer? She replied: [EMAIL PROTECTED]# A-C-2-4-0-V-/-5-0-H-Z http://www.cs.mu.oz.au/~trd # -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Differences of Debian vs. the Other Guys
At 23:38 -0700 1998-06-02, Tyson Dowd wrote: Manoj addressed most of the big differences in his mail. One that he missed (or glossed over) is the difference in generation of packages. Another one is that he didn't explain what dpkg-shlibdeps does. dpkg encourages (practically enforces) building a package in a working directory, installing files to a temporary directory, and packaging from that directory. e.g.configure --prefix ./debian/tmp make make install package up ./debian/tmp is what the debian/rules file says. That isn't the right way to do it, the executables may end up depending on being run from the same directory as the one they were built with (in practice, it doesn't seem that too many packages are like that, but it's good to keep it in mind). The correct way to do it (for most GNU autoconfized packages) is: ./configure --prefix=/usr make make install prefix=`pwd`/debian/tmp/usr In some cases this may cause a rebuild with the new path configured in, in which case it is necessary to do a bit more work in the rules. (The documentation for GNU stow is useful for a few strategies in dealing with such cases). -- Joel Espy Klecker Debian GNU/Linux Developer mailto:[EMAIL PROTECTED] http://web.espy.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Differences of Debian vs. the Other Guys
On 03-Jun-1998, Joel Klecker [EMAIL PROTECTED] wrote: At 23:38 -0700 1998-06-02, Tyson Dowd wrote: Manoj addressed most of the big differences in his mail. One that he missed (or glossed over) is the difference in generation of packages. Another one is that he didn't explain what dpkg-shlibdeps does. dpkg encourages (practically enforces) building a package in a working directory, installing files to a temporary directory, and packaging from that directory. e.g.configure --prefix ./debian/tmp make make install package up ./debian/tmp is what the debian/rules file says. That isn't the right way to do it, the executables may end up depending on being run from the same directory as the one they were built with (in practice, it doesn't seem that too many packages are like that, but it's good to keep it in mind). Oops, sorry, you are of course correct. -- Tyson Dowd # So I asked Sarah: what's the serial number on # your computer? She replied: [EMAIL PROTECTED]# A-C-2-4-0-V-/-5-0-H-Z http://www.cs.mu.oz.au/~trd # -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Differences of Debian vs. the Other Guys
Hi, Well, there are a number of things, but the following are important (in no particular order) 1) strong dependency tracking. Espescially with APT, the next generation replacement for dselect, packages are unpacked in an order that minimizes the time for which a package is unavailable during upgrades, packages may be held back if the dependecies are not filled. Conflicts: headers ensure that packages that may damage each other by being simultaneously installed are not ever on the same machine. 2) co-operation between packages and systems integration: a) the menu package (highjly flexible, with local overrides possible) b) the web standard This makes possible things like o) HTMLified documentation like http://localhost/doc/ and others o) standard location of the document root and cgi-bin makes it possible for packages to integrate themseles on the local http server c) kernel modules can be compiled while you are compiling the kernel so that they are in sync 3) install info, mime, and sgml tools help ensurte that all packages make full use of the info facility, and all SGML packages are available to SGML tools 4) Maintianer pre-post installation scripts -- look at sendmailconfig. It makes configuring _sendmail_ a breeze. 5) make-kpkg (from the kernel -package package -- look at /usr/doc/kernel-package/Rationale.gz as to the benefits of using it) 6) The Policy documents, and adherence to standards. 7) modular configuration of wondow managers like fvwm2 (one may have a very nice fvwm configuration with any amount of local ovber rides) 8) Shared libraries (dpkg-shlibs and friends) I can have multiple versions of the same library installed at once on Debian. 9) kernel flavours -- I can have multiple fkavours of the same kernel on my machine and not worry about the modules 10) The configurations for each installed kernel are stored in /boot 11) package upgades have a text based user interface (not everyone has X, you know) We are working on things like pre-fabricateed package selections (so one may select power-user or web-development or gaming or code-development and get a selection of relevant packages and defaults); we are investigating linuxconf. rpm vs dpkg - Dpkg uses `make' to drive the packaging process, which is running rings around the semi-shell-script type of stuff that RPM is using. For instance, in dpkg you can set a global variable at the beginning and use it throughout the rules file. In RPM (at least when I was working with it, you needed to use macros, which had limitations. You can also override variables at the command line. - In dpkg, you can include you own custom fields, and even have them show up when inspecting the package later. I was experimenting with adding CVS control information to our RPM setup. I ended up having to define macros in the rpm file and have a shell-script extract the values of these. I would much rather have extended the set of package control fields. - Dpkg uses a directory of control information. RPM forces you to jam all information into one big file. Apart from the lack of joy in editing large files with loads of unrelated information, it is also much easier to add you own custom extra pieces of information in a debian package. Just add another file to the debian directory. Dpkg will not care. - RPM depends on magic macros such as %setup which is used to unpack the source. You can have several %setup's but there is a hidden variable that remembers the resulting directory of the last %setup issued, which affects later sections. - In order to have RPM build a .rpm file, you need to run all steps in one go. That is you need to unpack the source, compile and package. You cannot at the end of a busy debugging session, just pack up the binaries lying all ready in your work directory. You need to remove it, and go from the top. Again, dpkg is much more flexible. - RPM does not have something like dpkg-shlibs. - (Probably not correct) RPMs package format is more complicated than the dpkg one. I do not know of a way to extract the files from an RPM package, without using the `rpm' tool. The .deb files are just `ar' archives containg a tar file. - The unconditional need to exhaustively declare all files that is to go into the RPM file. Usefull for the control freak but hell for the quick-and-dirty practioner in the initial stages of creating a package, especiallly given the need to recompile everytime you is to create a package. Advantages of using make-kpkg -- -- - - I have been asked several times about the advantages of using the kernel-package package over the traditional Linux way of hand compiling kernels, and I
Re: Differences of Debian vs. the Other Guys
On Tue, 2 Jun 1998, Javier Fernandez-Sanguino Pen~a wrote: What are the main differences/advantages/disadvantages of Debian's Packaging System vs The Other Guys (tm) ? I would appreciate any help in sorting these out (I already have So would we ! John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
