Re: Per-distro versioning and dependency specification

Congratulations on the ~~stupidest~~ least-well justified, most ill-thought-through recommendation I've seen in a very long time.

By reductio ad absurdum: Ubunto (substitute your favorite here) is a "distribution". It contains many "packages" -- over 1200 device drivers before you even start on the other components. If it incremented a single version 'number' every time any of those hundreds of subcomponents changed, it would seriously need to consider using 64-bit integers for each of the major(midor)minor components of the version 'number', lest it ran out of space.

Too big for this advise? How about GCC. If it incremented its version number every time one of it hundreds (thousands?) of subcomponents changed, its version numbers would read like a telephone numbers.

Still too big a project? At what point does this suggestion cease to be viable?

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Comment on Re: Per-distro versioning and dependency specification

Replies are listed 'Best First'.
Re^2: Per-distro versioning and dependency specification by creamygoodness (Curate) on Jun 06, 2012 at 12:26 UTC
I would draw the line around any group of files which can only be installed together. That was what the phrase "atomic unit of installation" was intended to convey. Ubuntu and GCC don't really fit into that context, as they are aggregations of smaller packages. Most CPAN tarballs would qualify, though, since `perl Makefile.PL; make install` is generally all or nothing.	[reply] [d/l]


Perl: the Markov chain saw
	PerlMonks