[nSLUG] Upgrade tools, or... (choosing a new distribution)

David Potter dlpotter at ns.sympatico.ca
Tue Sep 11 18:39:40 ADT 2007


Hi Ben,

I'm very sure that you've said this before... which speaks to the value 
of repetition - I just got it... ;-)

My "Mission Critical " requirement is Samba, and the accessories are 
Gnome and OpenOffice so I'm not putting real strain on any distribution.

I'm downloading the images now!

Thanks everyone!

David Potter


Ben Armstrong wrote:
> David,
>
> On Tue, 11 Sep 2007 08:09:45 -0300
> David Potter <dlpotter at ns.sympatico.ca> wrote:
>   
>> That certainly sounds like what I'm looking for... can it actually 
>> handle the number of dependency issues that seem to turn up when you 
>> upgrade between Debian distributions? And is this same (apt-get) tool 
>> available in other distributions?
>>     
>
> Put it this way: I have a system that has been installed and upgraded
> from a single install for a decade.  Debian does a reasonably good job
> at handling dependency issues, though the further you stray from a
> "pure Debian" system (i.e. "taint" it with packages of unknown quality
> from third party sources,) the more likely you are to screw things up.
> Also, upgrading within "testing/unstable" introduces issues you'll
> need to be prepared to deal with if you like to track the "cutting
> edge" rather than using the "stable" release.
>
> Yes, apt-get *is* available on other platforms, but the "secret sauce"
> that really makes the whole thing work is not apt; it is this document:
>
> http://www.debian.org/doc/debian-policy/
>
> Debian developers are bound by this policy manual to make packages that
> conform.  Non-conformant packages that violate "must" directives have
> release-critical bugs filed against them.  If they are not fixed by the
> time a new stable release comes out, those packages are removed from the
> distribution.  Packages in testing/unstable may have release-critical bugs
> in them, though it ought to be every developer's priority to fix these
> as soon as possible, whether on the brink of a release or not.
>
> I'll give you a couple of examples below.  Imagine a distribution with
> apt-get that does not follow these policies, and therefore allows
> packages to be shipped that violate the rules outlined in either section.
> And these are only two small sections of the whole document.  If you have
> the patience for it, I highly recommend reading the whole thing.  It will
> give you a better appreciation of what makes Debian so solid.  It will
> also help you spot and identify problems, and help get them resolved more
> speedily.
>
> To be fair, other distributions do have their own policies and standards
> for quality, but I think Debian has done a remarkable job in this domain
> that is too often misunderstood and glossed over by those who say "oh,
> apt-get is what make Debian so great; all we need is apt-get!"
>
>
> http://www.debian.org/doc/debian-policy/ch-binary.html#s3.5
>
> 3.5 Dependencies
>
> Every package must specify the dependency information about other packages
> that are required for the first to work correctly.
>
> For example, a dependency entry must be provided for any shared libraries
> required by a dynamically-linked executable binary in a package.
>
> Packages are not required to declare any dependencies they have on other
> packages which are marked Essential (see below), and should not do so unless
> they depend on a particular version of that package.[7]
>
> Sometimes, a package requires another package to be installed and configured
> before it can be installed. In this case, you must specify a Pre-Depends
> entry for the package.
>
> You should not specify a Pre-Depends entry for a package before this has
> been discussed on the debian-devel mailing list and a consensus about doing
> that has been reached.
>
> ...
>
> http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-idempotency
>
> 6.2 Maintainer scripts Idempotency
>
> It is necessary for the error recovery procedures that the scripts be
> idempotent. This means that if it is run successfully, and then it is
> called again, it doesn't bomb out or cause any harm, but just ensures
> that everything is the way it ought to be. If the first call failed, or
> aborted half way through for some reason, the second call should merely
> do the things that were left undone the first time, if any, and exit
> with a success status if everything is OK.
>
>
> Ben
> --
>  ,-.  nSLUG    http://www.nslug.ns.ca   synrg at sanctuary.nslug.ns.ca
>  \`'  Debian   http://www.debian.org    synrg at debian.org
>   `          [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
>              [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]
> _______________________________________________
> nSLUG mailing list
> nSLUG at nslug.ns.ca
> http://nslug.ns.ca/cgi-bin/mailman/listinfo/nslug
>
>   

-- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nslug.ns.ca/mailman/private/nslug/attachments/20070911/f0a853ab/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2007-Bench.jpg
Type: image/jpeg
Size: 17251 bytes
Desc: not available
URL: <http://nslug.ns.ca/mailman/private/nslug/attachments/20070911/f0a853ab/attachment-0002.jpg>


More information about the nSLUG mailing list