version control systems

[crankypuss]

Here's an article that I found interesting:
http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/

Since I'm currently most interested in Debian, I did some poking around
to see what version control system is used for Debian. I came away more
confused than not. <g>

--
http://totally-portable-software.blogspot.com
[Sun Nov 22: "Total Portability is not binary"]

[J.O. Aho]

On 12/28/2015 12:50 PM, crankypuss wrote:
> Here's an article that I found interesting:
> http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/
>
> Since I'm currently most interested in Debian, I did some poking around
> to see what version control system is used for Debian. I came away more
> confused than not. <g>
>

I would say that cvs you should forget, tools mostly there for legacy
reasons. Svn has it's issues specially when you are merging things.

I been using git, sure I don't know everything about it, I learn new
things from time to time, but using the basic functionality you can
already do a lot, you can take a look at this:
http://rogerdudler.github.io/git-guide

if you feel it's not for you you can try things like mecurial or any
other new version control systems out there and which you end up with
will most likely be just a question of taste and how your thought
process is.


--

//Aho

[John Hasler]

crankypuss writes:
> Since I'm currently most interested in Debian, I did some poking
> around to see what version control system is used for Debian.

Debian as such uses none: the question isn't relevant. Most developers use Git.
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

[crankypuss]

John Hasler wrote:

> crankypuss writes:
>> Since I'm currently most interested in Debian, I did some poking
>> around to see what version control system is used for Debian.
>
> Debian as such uses none: the question isn't relevant. Most
> developers use Git.

Uh, okay. What's used to maintain the Debian builds then? IOW if most
developers use Git, how do they then check their work in so it gets
included in the builds?

Maybe it's something that only Debian developers have a "need to know"?

[John Hasler]

crankypuss writes:
> What's used to maintain the Debian builds then? IOW if most
> developers use Git, how do they then check their work in so it gets
> included in the builds?

What "builds"? Each package is built seperately, either by the
maintainer or by the autobuilders, and then added to the archive. The
archive is maintained by custom software developed over the life of
Debian.

[J.O. Aho]

On 12/29/2015 03:30 AM, crankypuss wrote:

> if most
> developers use Git, how do they then check their work in so it gets
> included in the builds?

This is just in general, not directly connected to any project. You will
have different branches, a master branch which is what you have for the
live system, a development branch which is the upcoming system and then
you may have other branches one for each change. The
developer/maintainer then pushes his branch to the remote git
repository. Then someone reviews the branch changes and merge it to the
development branch if it passes the review. When you have a development
branch which works and have all the packages for the next generation,
then you merge it to master branch and tag the version on the master
branch and now others would be able to download the new packages.


If you are looking for debian development environment, then check this
page: https://www.debian.org/devel/buildd

Sure it allows you to have a git or another version control system in
the bottom, so when you make changes you can revert if there is
something wrong.

--

//Aho

[crankypuss]

John Hasler wrote:

> crankypuss writes:
>> What's used to maintain the Debian builds then? IOW if most
>> developers use Git, how do they then check their work in so it gets
>> included in the builds?
>
> What "builds"? Each package is built seperately, either by the
> maintainer or by the autobuilders, and then added to the archive. The
> archive is maintained by custom software developed over the life of
> Debian.

So "the archive" is basically a website with custom software.
Presumably each distro has its own archive/software?

[crankypuss]

From a brief look it seems like the info is there, I'll read it in
detail a bit later. Thanks.

[John Hasler]

J.O. Aho writes:
> If you are looking for debian development environment, then check this
> page: https://www.debian.org/devel/buildd

However note that there is no requirement that packages be built on the
autobuilders: developers can and do build packages on their own systems
and upload them to Incoming for whatever architecture they use. Also
note that when the autobuilders do build packages they go to Incoming
just like ones built directly by the developers. Normally the developer
uploads a source package plus a binary package for whatever architecture
he runs and the autobuilders build binaries for the other architectures.

There is a movement afoot to go to having all binaries built on the
autobuilder network. However, this will not really change the process:
it just means that developers will go to uploading source-only packages.

In Debian there is no unified Git-like source repository of all source
code nor is there a single giant build system that builds the entire
distribution as a unit. Each package is a seperate unit. Dependency
relationships among packages are handled on the package level and
described by standardized metadata in each package. This makes it
possible to build and upload to the archive a new version of a package
without necessarily making any changes to any other package.

[John Hasler]

crankypuss writes:
> So "the archive" is basically a website with custom software.

The Debian system is a large, complex, world-wide network. The archive
is the database from which the package management software on your
machine fetches packages. It has many mirrors around the world, most
not under the direct control of Debian. Digital signatures are used to
maintain security. The Security archive is an exception: it is never
mirrored.

Behind the archive is some truly amazing custom software developed over
the life of Debian.

[Chris Ahlstrom]

John Hasler wrote this copyrighted missive and expects royalties:

> crankypuss writes:
>> So "the archive" is basically a website with custom software.
>
> The Debian system is a large, complex, world-wide network. The archive
> is the database from which the package management software on your
> machine fetches packages. It has many mirrors around the world, most
> not under the direct control of Debian. Digital signatures are used to
> maintain security. The Security archive is an exception: it is never
> mirrored.
>
> Behind the archive is some truly amazing custom software developed over
> the life of Debian.

+1

--
Your temporary financial embarrassment will be relieved in a surprising manner.

[crankypuss]

John Hasler wrote:

> crankypuss writes:
>> So "the archive" is basically a website with custom software.
>
> The Debian system is a large, complex, world-wide network. The
> archive is the database from which the package management software on
> your
> machine fetches packages. It has many mirrors around the world, most
> not under the direct control of Debian. Digital signatures are used
> to
> maintain security. The Security archive is an exception: it is never
> mirrored.
>
> Behind the archive is some truly amazing custom software developed
> over the life of Debian.

LOL, I've seen some software that was "truly amazing" in the sense that
it worked at all. <g>

I wonder why we still have so many different version control systems;
they're all about doing one conceptually-simple thing, and even though
the range of their scaling is large, we ought to have been able to have
figured out the general case by now.

[crankypuss]

John Hasler wrote:

> J.O. Aho writes:
>> If you are looking for debian development environment, then check
>> this page: https://www.debian.org/devel/buildd
>
> However note that there is no requirement that packages be built on
> the autobuilders: developers can and do build packages on their own
> systems
> and upload them to Incoming for whatever architecture they use. Also
> note that when the autobuilders do build packages they go to Incoming
> just like ones built directly by the developers. Normally the
> developer uploads a source package plus a binary package for whatever
> architecture he runs and the autobuilders build binaries for the other
> architectures.
>
> There is a movement afoot to go to having all binaries built on the
> autobuilder network. However, this will not really change the
> process: it just means that developers will go to uploading
> source-only packages.

I think that might be an extremely good thing. The GPL requires
parallelism between a binary and its source, and currently puts the onus
of supplying the source code on the distributor of the binary. If both
come from the same source it seems as though it would become possible to
distribute a modification in binary that is "guaranteed" (by merit of
the way it's built) to have parallel source code available from the same
repository as the binary.

As an example of what I'm talking about, if I was to modify PHP such
that it was a "small" (conceptually, anyway) front-end to which the PHP
source code for an application was appended, thus making the PHP source
code a "standalone" binary that would run on any system architecturally
compatible with the front-end, current licensing requirements seem to
forbid such a thing unless the source code for the modified PHP front-
end is distributed along with the binary.

> In Debian there is no unified Git-like source repository of all source
> code nor is there a single giant build system that builds the entire
> distribution as a unit.

That seems like a good thing, it allows development outside the system
and integration into the system. One would want the system to rebuild
what the developer has constructed from what has been included into the
system, otherwise it's an error-magnet.

> Each package is a seperate unit. Dependency
> relationships among packages are handled on the package level and
> described by standardized metadata in each package.

IMO that is *extremely* messed up.

> This makes it
> possible to build and upload to the archive a new version of a package
> without necessarily making any changes to any other package.

Dependency relationships should be generated from the code, not from the
developer's memory or inclinations to "recommend" this or that.
Dependencies are simply what they are, the information is there in the
source.

[mm0fmf]

By all means go ahead and produce some software as it is so conceptually
simple. We all use it if it's any good.

[Chris Ahlstrom]

crankypuss wrote this copyrighted missive and expects royalties:

> John Hasler wrote:
>
>> crankypuss writes:
>>> So "the archive" is basically a website with custom software.
>>
>> The Debian system is a large, complex, world-wide network. The
>> archive is the database from which the package management software on
>> your
>> machine fetches packages. It has many mirrors around the world, most
>> not under the direct control of Debian. Digital signatures are used
>> to
>> maintain security. The Security archive is an exception: it is never
>> mirrored.
>>
>> Behind the archive is some truly amazing custom software developed
>> over the life of Debian.
>
> LOL, I've seen some software that was "truly amazing" in the sense that
> it worked at all. <g>
>
> I wonder why we still have so many different version control systems;

After a certain point, a rewrite is easier than wedging in some new
functionality?

Companies thinking they have a better mousetrap and can make some money on
it?

A noted developer who believed that Subversion was shit?

> they're all about doing one conceptually-simple thing, and even though
> the range of their scaling is large, we ought to have been able to have
> figured out the general case by now.

I can't decide if you're a lumper or a hair-splitter :-D

--
The naked truth of it is, I have no shirt.
-- William Shakespeare, "Love's Labour's Lost"

[Chris Ahlstrom]

crankypuss wrote this copyrighted missive and expects royalties:

> John Hasler wrote:
>

>> Each package is a seperate unit. Dependency
>> relationships among packages are handled on the package level and
>> described by standardized metadata in each package.
>
> IMO that is *extremely* messed up.
>
>> This makes it
>> possible to build and upload to the archive a new version of a package
>> without necessarily making any changes to any other package.
>
> Dependency relationships should be generated from the code, not from the
> developer's memory or inclinations to "recommend" this or that.
> Dependencies are simply what they are, the information is there in the
> source.

Not really. That's why they have "make" files.

--
You have many friends and very few living enemies.

[crankypuss]

Still busy trying to get Debian stretch installed identically on 3
different machines. Once I get past that it'll be time to pick up where
I left off a very long time ago.

> We all use it if it's any good.

That's one of the few things we can count on as a community, our
inherent laziness, it's what will save our asses in the long run because
"crap" is hard to use and "excellent software" just works.

[crankypuss]

Chris Ahlstrom wrote:

> crankypuss wrote this copyrighted missive and expects royalties:
>
>> John Hasler wrote:
>>
>>> crankypuss writes:
>>>> So "the archive" is basically a website with custom software.
>>>
>>> The Debian system is a large, complex, world-wide network. The
>>> archive is the database from which the package management software
>>> on your
>>> machine fetches packages. It has many mirrors around the world,
>>> most
>>> not under the direct control of Debian. Digital signatures are used
>>> to
>>> maintain security. The Security archive is an exception: it is
>>> never mirrored.
>>>
>>> Behind the archive is some truly amazing custom software developed
>>> over the life of Debian.
>>
>> LOL, I've seen some software that was "truly amazing" in the sense
>> that it worked at all. <g>
>>
>> I wonder why we still have so many different version control systems;
>
> After a certain point, a rewrite is easier than wedging in some new
> functionality?

That's entirely true imo, and it's also proof of-itself that the
mechanisms we use to express meaning are insufficiently developed in the
sense of not being abstracted enough to obviate the need for wedging-in.

> Companies thinking they have a better mousetrap and can make some
> money on it?

Greed is something one can rely on to obstruct real progress, that's why
demonetization is something we ought to do on purpose instead of just
letting the paperless economy fall down around us then realizing it
wasn't necessary to begin with.

> A noted developer who believed that Subversion was shit?

I missed that episode of The Drama Queen Show, details? I know nothing
about any of the "modern" control systems, they may *all* be shit for
all I know. The last [non-homegrown] version control system I've used
is Microsoft Visual Source Safe back in the early '90s, and *it* was
certainly... somewhat less than perfect.

>> they're all about doing one conceptually-simple thing, and even
>> though the range of their scaling is large, we ought to have been
>> able to have figured out the general case by now.
>
> I can't decide if you're a lumper or a hair-splitter :-D

If you abstract sufficiently it necessitates extreme precision, duh? <G>

[crankypuss]

I need to just let that statement stand instead of beginning a rant; be
glad, be very glad. <G>

[Richard Kettlewell]

Makefiles aren’t involved in inter-package dependencies.

Dependencies on libraries are indeed generated from the code, using
dpkg-shlibdeps. Other automation may be possible, I’ve not checked.
Other kinds of dependencies do need to be specified manually.

--
http://www.greenend.org.uk/rjk/

[crankypuss]

Specifically non-code components, like default configuration files
(which imo ought to be generated by the code on first-run), and doc
files (which imo ought to become dependants because the code actually
displays them ).

If you can come up with some actual examples of other dependencies that
cannot be automatically determined, please provide them; I'm of the
opinion that there should be zero.

[Chris Ahlstrom]

crankypuss wrote this copyrighted missive and expects royalties:

> Chris Ahlstrom wrote:
>
>> A noted developer who believed that Subversion was shit?
>
> I missed that episode of The Drama Queen Show, details?

https://www.youtube.com/watch?v=idLyobOhtO4

> I know nothing
> about any of the "modern" control systems, they may *all* be shit for
> all I know. The last [non-homegrown] version control system I've used
> is Microsoft Visual Source Safe back in the early '90s, and *it* was
> certainly... somewhat less than perfect.

The follow on, Team Foundation, broke the build process of one of our
dev groups, a few years back.

They ended up migrating to another wonderful product, MSBuild (Microsoft
innovates Apache Ant).

>>> they're all about doing one conceptually-simple thing, and even
>>> though the range of their scaling is large, we ought to have been
>>> able to have figured out the general case by now.
>>
>> I can't decide if you're a lumper or a hair-splitter :-D
>
> If you abstract sufficiently it necessitates extreme precision, duh? <G>

I thought extreme precision was merely a tool for trolls!

--
Q: How many lawyers does it take to change a light bulb?
A: Whereas the party of the first part, also known as "Lawyer", and the
party of the second part, also known as "Light Bulb", do hereby and forthwith
agree to a transaction wherein the party of the second part shall be removed
from the current position as a result of failure to perform previously agreed
upon duties, i.e., the lighting, elucidation, and otherwise illumination of
the area ranging from the front (north) door, through the entryway, terminating
at an area just inside the primary living area, demarcated by the beginning of
the carpet, any spillover illumination being at the option of the party of the
second part and not required by the aforementioned agreement between the
parties.
The aforementioned removal transaction shall include, but not be
limited to, the following. The party of the first part shall, with or without
elevation at his option, by means of a chair, stepstool, ladder or any other
means of elevation, grasp the party of the second part and rotate the party
of the second part in a counter-clockwise direction, this point being tendered
non-negotiable. Upon reaching a point where the party of the second part
becomes fully detached from the receptacle, the party of the first part shall
have the option of disposing of the party of the second part in a manner
consistent with all relevant and applicable local, state and federal statutes.
Once separation and disposal have been achieved, the party of the first part
shall have the option of beginning installation. Aforesaid installation shall
occur in a manner consistent with the reverse of the procedures described in
step one of this self-same document, being careful to note that the rotation
should occur in a clockwise direction, this point also being non-negotiable.
The above described steps may be performed, at the option of the party of the
first part, by any or all agents authorized by him, the objective being to
produce the most possible revenue for the Partnership.

[Chris Ahlstrom]

crankypuss wrote this copyrighted missive and expects royalties:

> Richard Kettlewell wrote:
>
>> Chris Ahlstrom <OFee...@teleworm.us> writes:
>>> crankypuss wrote this copyrighted missive and expects royalties:
>>>> John Hasler wrote:
>>>>> Each package is a seperate unit. Dependency relationships among
>>>>> packages are handled on the package level and described by
>>>>> standardized metadata in each package.
>>>>
>>>> IMO that is *extremely* messed up.
>>>>
>>>>> This makes it possible to build and upload to the archive a new
>>>>> version of a package without necessarily making any changes to any
>>>>> other package.
>>>>
>>>> Dependency relationships should be generated from the code, not from
>>>> the developer's memory or inclinations to "recommend" this or that.
>>>> Dependencies are simply what they are, the information is there in
>>>> the source.
>>>
>>> Not really. That's why they have "make" files.
>>
>> Makefiles aren’t involved in inter-package dependencies.

Duh.

>> Dependencies on libraries are indeed generated from the code, using
>> dpkg-shlibdeps. Other automation may be possible, I’ve not checked.
>
>> Other kinds of dependencies do need to be specified manually.
>
> Specifically non-code components, like default configuration files
> (which imo ought to be generated by the code on first-run), and doc
> files (which imo ought to become dependants because the code actually
> displays them ).
>
> If you can come up with some actual examples of other dependencies that
> cannot be automatically determined, please provide them; I'm of the
> opinion that there should be zero.

What do you think this is? Java?

Hell, even Java needs help specifying dependencies.

--
An exotic journey in downtown Newark is in your future.

[John Hasler]

crankypuss writes:
> I wonder why we still have so many different version control systems;
> they're all about doing one conceptually-simple thing, and even though
> the range of their scaling is large, we ought to have been able to
> have figured out the general case by now.

We have. It's called "Git".

[crankypuss]

Chris Ahlstrom wrote:

> crankypuss wrote this copyrighted missive and expects royalties:
>
>> Chris Ahlstrom wrote:
>>
>>> A noted developer who believed that Subversion was shit?
>>
>> I missed that episode of The Drama Queen Show, details?
>
> https://www.youtube.com/watch?v=idLyobOhtO4

Sorry, I don't do videos. Metered broadband.

>> I know nothing
>> about any of the "modern" control systems, they may *all* be shit for
>> all I know. The last [non-homegrown] version control system I've
>> used is Microsoft Visual Source Safe back in the early '90s, and *it*
>> was certainly... somewhat less than perfect.
>
> The follow on, Team Foundation, broke the build process of one of our
> dev groups, a few years back.
>
> They ended up migrating to another wonderful product, MSBuild
> (Microsoft innovates Apache Ant).

We here in the 'States live in a plutocracy billed as a representative
republic and commonly believed to be a democracy.

>>>> they're all about doing one conceptually-simple thing, and even
>>>> though the range of their scaling is large, we ought to have been
>>>> able to have figured out the general case by now.
>>>
>>> I can't decide if you're a lumper or a hair-splitter :-D
>>
>> If you abstract sufficiently it necessitates extreme precision, duh?
>> <G>
>
> I thought extreme precision was merely a tool for trolls!

"In Internet slang, a troll (/ˈtroʊl/, /ˈtrɒl/) is a person who sows
discord on the Internet by starting arguments or upsetting people, by
posting inflammatory,[1] extraneous, or off-topic messages in an online
community (such as a newsgroup, forum, chat room, or blog) with the
deliberate intent of provoking readers into an emotional response[2] or
of otherwise disrupting normal on-topic discussion,[3] often for their
own amusement."
https://en.wikipedia.org/wiki/Internet_troll


I wonder if there's a corresponding word to describe those of us who
post potentially-inflammatory comments with the intent of generating
sufficiently passionate discussion to instigate actual change. If so,
the same word would doubtless have an antipathetic definition in for-
profit corporate dictionaries.

[crankypuss]

I always like to hear that the competition sucks, thanks. <g>

[John Hasler]

I wrote:
> There is a movement afoot to go to having all binaries built on the
> autobuilder network. However, this will not really change the
> process: it just means that developers will go to uploading
> source-only packages.

Chris Ahlstrom writes:
> I think that might be an extremely good thing. The GPL requires
> parallelism between a binary and its source, and currently puts the
> onus of supplying the source code on the distributor of the binary.
> If both come from the same source it seems as though it would become
> possible to distribute a modification in binary that is "guaranteed"
> (by merit of the way it's built) to have parallel source code
> available from the same repository as the binary.

You misunderstand. The Debian source package always contains exactly
the source that was used to build the binary in the binary package. It
is what the binary package was built from, whether by the developer or
an autobuilder. Your guarantee is already there.

[crankypuss]

John Hasler wrote:

> crankypuss writes:
>> I wonder why we still have so many different version control systems;
>> they're all about doing one conceptually-simple thing, and even
>> though the range of their scaling is large, we ought to have been
>> able to have figured out the general case by now.
>
> We have. It's called "Git".

Okay, I can provisionally accept that. I look forward to learning how
Git performs the basic functions:

a) Obtain a current modifiable copy of a specific version of a specific
project,
b) Update the archive with changed components from (a),
c) Promote a project to the next stability-level,
d) Include end-user bug reports to "veto" promotion,
e) Resolve the possibility of personal interest causing spurious vetos.

That's what I see as the basics, actually building executable code from
project components (should that be necessary) is purely mechanical
compared to a-e (especially e!).

[Anybody else notice that knode "Platform Version 4.14.2" requires you
to click in the "Followup-To" field? What a PITA, didn't anybody try
the thing before shipping it, and if they did how could they miss this?]

[Richard Kettlewell]

Chris Ahlstrom <OFee...@teleworm.us> writes:
> crankypuss wrote this copyrighted missive and expects royalties:
>> Richard Kettlewell wrote:
>>> Chris Ahlstrom <OFee...@teleworm.us> writes:
>>>> crankypuss wrote this copyrighted missive and expects royalties:

>>>>> Dependency relationships should be generated from the code, not from
>>>>> the developer's memory or inclinations to "recommend" this or that.
>>>>> Dependencies are simply what they are, the information is there in
>>>>> the source.
>>>>
>>>> Not really. That's why they have "make" files.
>>>
>>> Makefiles aren’t involved in inter-package dependencies.
>
> Duh.
>
>>> Dependencies on libraries are indeed generated from the code, using
>>> dpkg-shlibdeps. Other automation may be possible, I’ve not checked.
>>
>>> Other kinds of dependencies do need to be specified manually.
>>
>> Specifically non-code components, like default configuration files
>> (which imo ought to be generated by the code on first-run), and doc
>> files (which imo ought to become dependants because the code actually
>> displays them ).

Config files are (almost always) part of the package rather than
separate packages. So package dependencies aren’t relevant here.

In many cases the same is true of documentation. Not all, though. For
instance in jessie:

$ awk -F: '/^(Depends|Suggests|Recommends):.*-doc[^-]/{print $1}' available|sort|uniq -c
18 Depends
19 Recommends
134 Suggests

The separation is probably mostly due to storage constraints and, in
some cases, copyright issues.

It’s quite possible that some degree of automation would be practical
but the choice between the three kinds of dependency is likeley to be a
policy decision. Even if it wasn’t the saving in effort would be tiny:
adding a single package to the relavant bit of debian/control is trivial
compared even to just the -doc package’s metadata and description in the
same file.

>> If you can come up with some actual examples of other dependencies that
>> cannot be automatically determined, please provide them; I'm of the
>> opinion that there should be zero.
>
> What do you think this is? Java?
>
> Hell, even Java needs help specifying dependencies.

For lots of concrete examples, inspect the debian/control files in
Debian source packages. I’m sure any missing automation that actually
produced the rights answers would be welcomed.

--
http://www.greenend.org.uk/rjk/

[John Hasler]

I wrote:
> Each package is a seperate unit. Dependency relationships among
> packages are handled on the package level and described by
> standardized metadata in each package.

crankypuss writes:
> IMO that is *extremely* messed up.

I wrote:
> This makes it possible to build and upload to the archive a new
> version of a package without necessarily making any changes to any
> other package.

crankypuss writes:
> Dependency relationships should be generated from the code, not from
> the developer's memory or inclinations to "recommend" this or that.
> Dependencies are simply what they are, the information is there in the
> source.

Wrong. The programs in different packages are only related at the
process level (except for libraries, and there is automation for that).
Sometimes the dependency is only at the documentation level, or even
only at the user requirements level. In many cases it would be possible
to totally rewrite a package in a different language without impacting
any dependencies. Dependencies operate off of the Debian version
number, not file hashes.

Also understand that dependencies are there for the use of the package
management system running on your machine, not for the use of some
central build system. Consistency in the Testing and Stable archives is
enforced by not allowing a package to transition from Unstable to Testing
until all of its dependencies can be satisfied (the archive management
software handles that).

Debian dependencies are much more complex than the simple "if it changes
rebuild" of a typical revision control system. There can be ranges,
exclusions, conflicts, provides, and virtual packages, for example. A
new version of a library may or may not require that packages using it be
rebuilt: the so number tells you that.

BTW you are free to ignore "Recommends". That is why they are called
that.

[John Hasler]

crankypuss writes:
> If you can come up with some actual examples of other dependencies
> that cannot be automatically determined, please provide them; I'm of
> the opinion that there should be zero.

You've got it mostly backwards. Your approach would create an enourmous
amount of pointless churn and make the archive unmanageable. Every time
a developer fixed a typo in a comment you would have a dozen others
being forced to rebuild their packages and upload new versions (which
would trigger a cascade of other uploads...)

BTW most dependencies are on libraries. These are handled
automatically, but not as simplistically as in a version control system.

Again, don't forget that there is no central all-dancing all-singing
monolithic build system. The dependencies are there for the use of the
package management system on the user's computer and for the archive
software to use to enforce consistency (but Unstable is usable without
it).

[John Hasler]

Incorrect attribution. Should be crankypuss. Sorry.

[mm0fmf]

Bellend?

[crankypuss]

The British talk funny, and corporate flunkies are always recognizable.

[crankypuss]

John Hasler wrote:

> crankypuss writes:
>> If you can come up with some actual examples of other dependencies
>> that cannot be automatically determined, please provide them; I'm of
>> the opinion that there should be zero.
>
> You've got it mostly backwards.

That's a change, generally I do things "inside out" with respect to what
everyone else is doing.

> Your approach would create an
> enourmous
> amount of pointless churn and make the archive unmanageable.

Maybe, but I'm not sure what my approach is, care to fill me in on which
conclusions you've jumped to?

> Every
> time a developer fixed a typo in a comment you would have a dozen
> others being forced to rebuild their packages and upload new versions
> (which would trigger a cascade of other uploads...)

I don't think so. Maybe we're talking about two approaches, including
the one you've concluded is "my approach".

> BTW most dependencies are on libraries. These are handled
> automatically, but not as simplistically as in a version control
> system.

Yeah, "my approach" says that libraries are a bad thing, a kludge stuck
on where there should be none.

> Again, don't forget that there is no central all-dancing all-singing
> monolithic build system.

So it goes, maybe that's because the itty bitty ones aren't adequately
scalable, or maybe something else is messed up, I dunno much about
what's being used this week.

Remember the old Woodie Allen movie, "Sleeper"? Consider me to have
been asleep for a decade or two, and on waking up I'm saying "WTF, you
guys *still* haven't caught up???"

> The dependencies are there for the use of
> the package management system on the user's computer and for the
> archive software to use to enforce consistency (but Unstable is usable
> without it).

Whatever flies your kite. I'm tired of my kite being jerked around by
other peoples' strings.

[Chris Ahlstrom]

John Hasler wrote this copyrighted missive and expects royalties:

> I wrote:
>> There is a movement afoot to go to having all binaries built on the
>> autobuilder network. However, this will not really change the
>> process: it just means that developers will go to uploading
>> source-only packages.
>
> Chris Ahlstrom writes:

No I didn't. Crankypuss writes:

>> I think that might be an extremely good thing. The GPL requires
>> parallelism between a binary and its source, and currently puts the
>> onus of supplying the source code on the distributor of the binary.
>> If both come from the same source it seems as though it would become
>> possible to distribute a modification in binary that is "guaranteed"
>> (by merit of the way it's built) to have parallel source code
>> available from the same repository as the binary.
>
> You misunderstand. The Debian source package always contains exactly
> the source that was used to build the binary in the binary package. It
> is what the binary package was built from, whether by the developer or
> an autobuilder. Your guarantee is already there.
> --
> John Hasler
> jha...@newsguy.com
> Dancing Horse Hill
> Elmwood, WI USA

--
Q: How many surrealists does it take to change a light bulb?
A: Two, one to hold the giraffe, and the other to fill the bathtub
with brightly colored machine tools.

[Surrealist jokes just aren't my cup of fur. Ed.]

[Chris Ahlstrom]

John Hasler wrote this copyrighted missive and expects royalties:

> Incorrect attribution. Should be crankypuss. Sorry.

Sorry for my premature correction :-)

--
You are number 6! Who is number one?

[crankypuss]

John Hasler wrote:

> I wrote:
>> Each package is a seperate unit. Dependency relationships among
>> packages are handled on the package level and described by
>> standardized metadata in each package.
>
> crankypuss writes:
>> IMO that is *extremely* messed up.
>
> I wrote:
>> This makes it possible to build and upload to the archive a new
>> version of a package without necessarily making any changes to any
>> other package.
>
> crankypuss writes:
>> Dependency relationships should be generated from the code, not from
>> the developer's memory or inclinations to "recommend" this or that.
>> Dependencies are simply what they are, the information is there in
>> the source.
>
> Wrong.

Oh, my.

> The programs in different packages are only related at the
> process level (except for libraries, and there is automation for
> that). Sometimes the dependency is only at the documentation level, or
> even
> only at the user requirements level. In many cases it would be
> possible to totally rewrite a package in a different language without
> impacting
> any dependencies. Dependencies operate off of the Debian version
> number, not file hashes.
>
> Also understand that dependencies are there for the use of the package
> management system running on your machine, not for the use of some
> central build system. Consistency in the Testing and Stable archives
> is enforced by not allowing a package to transition from Unstable to
> Testing until all of its dependencies can be satisfied (the archive
> management software handles that).
>
> Debian dependencies are much more complex than the simple "if it
> changes
> rebuild" of a typical revision control system. There can be ranges,
> exclusions, conflicts, provides, and virtual packages, for example. A
> new version of a library may or may not require that packages using it
> be rebuilt: the so number tells you that.
>
> BTW you are free to ignore "Recommends". That is why they are called
> that.

Okay, you're allowed to "win" if you wish. I don't care whether I win
or not, but I'd prefer not to "lose", and the always-available
alternative of "not playing" is, after all, always available. I don't
have to keep up my prestige with the boss in order to eat food and sleep
in a warm place. And I'm old enough to be in an entirely different
situation, I could be trying to live on Social Security in some city
where the property taxes alone would eat my food before I could buy it.

I don't yet know a lot about how things are currently being done, but
I've heard enough clues to tell me they could be better.

Likewise the install process could be cleaned up hugely. For example:
Because I have crappy weather-dependent call-volume-dependent metered
wireless broadband, I was downloading the ISO for DVD1 which is 4GiB in
size. You cannot get through that install on an ASUS T100 without
network connectivity; it can't be done, and if you can do it I'll buy
you a beer. On the other hand, once I used a Pantech UML295 aircard for
initial connectivity (the installer is older, doesn't have the constant-
reset bug yet) and rebooted, that connectivity was gone because the
*installed* version contains a more-recent bug that makes the Pantech
295 unusable because it's constantly resetting the thing. So I have to
resort to tethering my BlackBerry OS-10 phone in order to download the
drivers needed to get wifi working instead of claiming there are no
network devices.

Now, the first issue is the total uselessness of the "DVD1" ISO even
being built because it *requires* network connectivity. Unless you have
a phone you can tether or some other kind of connectivity, it does not
work for network-free installs. Now, someone will remind me that the
doc says "unreliable network" and try to weasel out of it that way, but
the fact is it *requires* the *network* in order to function, so it's
pointless to even build the things. If your system is so great why is
it being built? I was able to download the netinst which is only 365MiB
plus-or-minus, one *TWELFTH* the size of the useless "DVD1" ISO, and it
did the install perfectly (at least as far as I've tested it). Either
come clean and admit that the network is *required* for an install, or
make the "DVD1" ISO install with zero network connectivity; anything
else is massively beneath the dignity of any self-respecting developer.

That's just the install process. Then there are bugs introduced into
applications where they did not formerly exist. And options removed
from formerly useful programs, or garbage inserted with no way to remove
it.

Not to worry, I'm not going to change the systems and processes you
[plural] are so in love with. I'll just continue to complain about them
while I'm programming their replacement.

[mm0fmf]

On 30/12/2015 19:53, crankypuss wrote:

> Not to worry, I'm not going to change the systems and processes you
> [plural] are so in love with. I'll just continue to complain about them
> while I'm programming their replacement.
>

What an arsehole. *plonk*

[Jasen Betts]

On 2015-12-30, crankypuss <inv...@invalid.invalid> wrote:

> Still busy trying to get Debian stretch installed identically on 3
> different machines. Once I get past that it'll be time to pick up where
> I left off a very long time ago.

If you want identical, perhps try FAI

--
\_(ツ)_

[crankypuss]

I assume that you mean
http://fai-project.org/
and not any of these other many meanings of FAI:
https://en.wikipedia.org/wiki/FAI

Thanks for mentioning it, I don't recall ever having heard of it before.

[Jasen Betts]

On 2015-12-31, crankypuss <inv...@invalid.invalid> wrote:
> Jasen Betts wrote:
>
>> On 2015-12-30, crankypuss <inv...@invalid.invalid> wrote:
>>
>>> Still busy trying to get Debian stretch installed identically on 3
>>> different machines. Once I get past that it'll be time to pick up
>>> where I left off a very long time ago.
>>
>> If you want identical, perhps try FAI
>
> I assume that you mean
> http://fai-project.org/

I was thinking https://wiki.debian.org/FAI

but yeah it's the exact same thing.



--
\_(ツ)_

[crankypuss]

Looking through the web pages, I'm not seeing a whole lot of mention of
its ability to handle various (potentially vendor-specific) drivers, and
different machine configurations, like when one system is 32-bit only,
one is 64-bit with 32-bit UEFI firmware, etc.

Maybe it can handle the automated finding and installing of the correct
drivers. But if it can, then why doesn't the base Debian installer
handle that a little more gracefully then not handling it at all? I
must have installed stretch a dozen times over the past few weeks, and I
haven't even seen it ask whether or not I'm willing to use non-free
drivers , much less say "device XXXX found, do you want to install its
non-free driver, or not use the device?" It's tough-luck-charley-go-
dig-it-up.

So it's interesting, but until I can fully back up what I have, I'm not
in a position to try it.

[Chris Ahlstrom]

crankypuss wrote this copyrighted missive and expects royalties:

> Jasen Betts wrote:
>
>> On 2015-12-31, crankypuss <inv...@invalid.invalid> wrote:
>>> Jasen Betts wrote:
>>>
>>>> On 2015-12-30, crankypuss <inv...@invalid.invalid> wrote:
>>>>
>>>>> Still busy trying to get Debian stretch installed identically on 3
>>>>> different machines. Once I get past that it'll be time to pick up
>>>>> where I left off a very long time ago.
>>>>
>>>> If you want identical, perhps try FAI
>>>
>>> I assume that you mean
>>> http://fai-project.org/
>>
>> I was thinking https://wiki.debian.org/FAI
>>
>> but yeah it's the exact same thing.
>
> Looking through the web pages, I'm not seeing a whole lot of mention of
> its ability to handle various (potentially vendor-specific) drivers, and
> different machine configurations, like when one system is 32-bit only,
> one is 64-bit with 32-bit UEFI firmware, etc.

Dude, Debian will enumerate your hardware and load the appropriate modules
at boot time.

In rare cases you may have to set up the configuration (/etc/modules)
to load drivers for uncooperative hardware.

> Maybe it can handle the automated finding and installing of the correct
> drivers. But if it can, then why doesn't the base Debian installer
> handle that a little more gracefully then not handling it at all? I
> must have installed stretch a dozen times over the past few weeks, and I
> haven't even seen it ask whether or not I'm willing to use non-free
> drivers , much less say "device XXXX found, do you want to install its
> non-free driver, or not use the device?" It's tough-luck-charley-go-
> dig-it-up.

I believe that is something you have to initiate yourself. Not sure, it's
been a few months since I did a Debian (Sid) install.

--
My only love sprung from my only hate!
Too early seen unknown, and known too late!
-- William Shakespeare, "Romeo and Juliet"

[Mark Carroll]

On 01 Jan 2016, Chris Ahlstrom wrote:

> crankypuss wrote this copyrighted missive and expects royalties:

(snip)

>> I
>> must have installed stretch a dozen times over the past few weeks, and I
>> haven't even seen it ask whether or not I'm willing to use non-free
>> drivers , much less say "device XXXX found, do you want to install its
>> non-free driver, or not use the device?" It's tough-luck-charley-go-
>> dig-it-up.
>
> I believe that is something you have to initiate yourself. Not sure, it's
> been a few months since I did a Debian (Sid) install.

I'm pretty sure I've seen jessie netinst suggest to me drivers from
firmware-linux-nonfree like tg3_tso5. They didn't come on the CD image,
but it was happy to accept them from removable media so I just put the
bin files on a flash drive and then the installer happily continued.
I've no idea about sid.

-- Mark

[Chris Ahlstrom]

Mark Carroll wrote this copyrighted missive and expects royalties:

Aside from Sid, the other wrinkle to my installs is that I start with a
basic "testing" netinstall, then change /etc/apt/sources.list to install
the rest from Sid.

--
Your step will soil many countries.

[crankypuss]

Chris Ahlstrom wrote:

> crankypuss wrote this copyrighted missive and expects royalties:
>
>> Jasen Betts wrote:
>>
>>> On 2015-12-31, crankypuss <inv...@invalid.invalid> wrote:
>>>> Jasen Betts wrote:
>>>>
>>>>> On 2015-12-30, crankypuss <inv...@invalid.invalid> wrote:
>>>>>
>>>>>> Still busy trying to get Debian stretch installed identically on
>>>>>> 3
>>>>>> different machines. Once I get past that it'll be time to pick
>>>>>> up where I left off a very long time ago.
>>>>>
>>>>> If you want identical, perhps try FAI
>>>>
>>>> I assume that you mean
>>>> http://fai-project.org/
>>>
>>> I was thinking https://wiki.debian.org/FAI
>>>
>>> but yeah it's the exact same thing.
>>
>> Looking through the web pages, I'm not seeing a whole lot of mention
>> of its ability to handle various (potentially vendor-specific)
>> drivers, and different machine configurations, like when one system
>> is 32-bit only, one is 64-bit with 32-bit UEFI firmware, etc.
>
> Dude, Debian will enumerate your hardware and load the appropriate
> modules at boot time.
>
> In rare cases you may have to set up the configuration (/etc/modules)
> to load drivers for uncooperative hardware.

I don't know what values "rare" might have, but I do know that for 2 of
my 3 laptops, it was necessary to manually install the correct driver
and firmware. Both were proprietary (Broadcom), and the installer never
even asked if I wanted to enable a non-free repository.

I'm fully aware that the kernel will discover hardware and attempt to
load the appropriate driver, and imo it does a very good job of that
*when* the driver has been installed (present in the expected place).

Since the installer can also discover hardware and get its vendor-id,
it's unclear to me why this business is so poorly handled by the
installer. Probably just another case of "nobody got around to that
yet" because of resource constraints. It's a table-lookup after all.

>> Maybe it can handle the automated finding and installing of the
>> correct
>> drivers. But if it can, then why doesn't the base Debian installer
>> handle that a little more gracefully then not handling it at all? I
>> must have installed stretch a dozen times over the past few weeks,
>> and I haven't even seen it ask whether or not I'm willing to use
>> non-free drivers , much less say "device XXXX found, do you want to
>> install its
>> non-free driver, or not use the device?" It's tough-luck-charley-go-
>> dig-it-up.
>
> I believe that is something you have to initiate yourself. Not sure,
> it's been a few months since I did a Debian (Sid) install.

According to what I've picked up over the airwaves, you have never done
a sid install; there *are* no sid ISO images built, so you installed
something else then upgraded a copy of it to sid, nyet?

Terminology is *such* a bitch, ain't it? <G>

[Chris Ahlstrom]

crankypuss wrote this copyrighted missive and expects royalties:

> Chris Ahlstrom wrote:
>
>> crankypuss wrote this copyrighted missive and expects royalties:
>>

>>> Looking through the web pages, I'm not seeing a whole lot of mention
>>> of its ability to handle various (potentially vendor-specific)
>>> drivers, and different machine configurations, like when one system
>>> is 32-bit only, one is 64-bit with 32-bit UEFI firmware, etc.
>>
>> Dude, Debian will enumerate your hardware and load the appropriate
>> modules at boot time.
>>
>> In rare cases you may have to set up the configuration (/etc/modules)
>> to load drivers for uncooperative hardware.
>
> I don't know what values "rare" might have, but I do know that for 2 of
> my 3 laptops, it was necessary to manually install the correct driver
> and firmware. Both were proprietary (Broadcom), and the installer never
> even asked if I wanted to enable a non-free repository.

I was talking about after the installation, to clarify.

I've had to deal with Broadcom in the past, using the wired NIC to
do the install and then to add the Broadcomm drivers and/or non-free
firmware in order to enable the wireless. After enabling the
non-free repository manually, which you've verified is still the
case with Debian.

> I'm fully aware that the kernel will discover hardware and attempt to
> load the appropriate driver, and imo it does a very good job of that
> *when* the driver has been installed (present in the expected place).

Yeah, I see what you're getting at, now.

> Since the installer can also discover hardware and get its vendor-id,
> it's unclear to me why this business is so poorly handled by the
> installer. Probably just another case of "nobody got around to that
> yet" because of resource constraints. It's a table-lookup after all.
>

>> I believe that is something you have to initiate yourself. Not sure,
>> it's been a few months since I did a Debian (Sid) install.
>
> According to what I've picked up over the airwaves, you have never done
> a sid install; there *are* no sid ISO images built, so you installed
> something else then upgraded a copy of it to sid, nyet?
>
> Terminology is *such* a bitch, ain't it? <G>

Well, to me, it is a Sid install. To Debian, too:

https://wiki.debian.org/InstallFAQ

If you are aware of the risks of running unstable, but still want to
install it, you have three choices:

Use the stable installer to install a minimal stable system and then
change your /etc/apt/sources.list file to point to "unstable" and do an
update and a dist-upgrade. Finally, install the packages you desire. This
method is the most likely to work of those presented here.

Be a tester of the "testing" installer and install "testing" using a
netinst image, then upgrade to "unstable" by changing the entries in your
/etc/apt/sources.list (change each occurrence of "testing" to
"unstable"). To avoid unnecessary downloads and package upgrades,
it is advisable to install a minimal "testing" system first and only to
install most of the software (e.g. desktop environment) after the switch
to "unstable". Then apt-get update and apt-get -u dist-upgrade - then you
have a sid release.

Use netboot "mini.iso" image. You will find it on any of the Debian
mirrors under
debian/dists/unstable/main/installer-*/current/images/netboot/mini.iso.
During the installation choose "Advanced options" -> "Expert install". In
the step "Choose a mirror of the Debian archive" choose version "sid -
unstable".

I use the second method. But hmmm, might be good to try that mini ISO
image some time.

--
Gone With The Wind LITE(tm)
-- by Margaret Mitchell

A woman only likes men she can't have and the South gets trashed.

Gift of the Magi LITE(tm)
-- by O. Henry

A husband and wife forget to register their gift preferences.

The Old Man and the Sea LITE(tm)
-- by Ernest Hemingway

An old man goes fishing, but doesn't have much luck.

[Jasen Betts]

On 2016-01-01, crankypuss <inv...@invalid.invalid> wrote:
>
> I don't know what values "rare" might have, but I do know that for 2 of
> my 3 laptops, it was necessary to manually install the correct driver
> and firmware. Both were proprietary (Broadcom), and the installer never
> even asked if I wanted to enable a non-free repository.

Are you running the installer in expert mode? that enables all sorts
of neat features.

--
\_(ツ)_

[crankypuss]

Doesn't that impress you as kind of backwards? Helping non-experts to
obtain/install the necessary drivers is something only available in
"expert mode"? Go figure. <g>

[Kirk_Von_Rockstein]

On 2016-01-01, crankypuss <inv...@invalid.invalid> wrote:

<snip>

> According to what I've picked up over the airwaves, you have never done
> a sid install; there *are* no sid ISO images built, so you installed
> something else then upgraded a copy of it to sid, nyet?

<snip>

Hey crank, On the SID ISO...

http://news.siduction.org/2015/12/release-notes-for-2015-1-dev-release/
http://forum.siduction.org/index.php?page=download-mirrors-en

I think it is what you been looking for...

[crankypuss]

Interesting, thanks for mentioning it. OTOH the stretch netinst works
better than the DVD1 ISO and I already have that (mostly) installed, so
it's likely that I'll just copy it to my other machines and then change
the repos and update to sid. If I'd known about siduction earlier it
might have saved me some frustration but it still would be a big
download compared to the netinst. I'll stick with pure Debian (what's
the "Deb" part from anyway?) instead of switching horses just now, if I
was to switch from plain-old Debian at this point it would probably be
toward Mageia or something else, Gentoo maybe, or Hurd if that's ready
this year. <g>

[Mark Carroll]

On 04 Jan 2016, crankypuss wrote:
(snip)

> Interesting, thanks for mentioning it. OTOH the stretch netinst works
> better than the DVD1 ISO and I already have that (mostly) installed, so
> it's likely that I'll just copy it to my other machines and then change
> the repos and update to sid.

Ah, yes, I've usually used the netinst, so that might have helped me.

> I'll stick with pure Debian (what's the "Deb" part from anyway?)

https://wiki.debian.org/DebianName has "Debra was Ian's girlfriend".
They were married for some years.

(snip)

> or Hurd if that's ready this year. <g>

Heh, I've been waiting for years. Maybe someday! More recently I had
half an eye on GuixSD too in case that got further with Hurd first.
Perhaps that Linux works so well means reduces any need for Hurd.

-- Mark

[crankypuss]

Mark Carroll wrote:

> On 04 Jan 2016, crankypuss wrote:
> (snip)
>> Interesting, thanks for mentioning it. OTOH the stretch netinst
>> works better than the DVD1 ISO and I already have that (mostly)
>> installed, so it's likely that I'll just copy it to my other machines
>> and then change the repos and update to sid.
>
> Ah, yes, I've usually used the netinst, so that might have helped me.
>
>> I'll stick with pure Debian (what's the "Deb" part from anyway?)
>
> https://wiki.debian.org/DebianName has "Debra was Ian's girlfriend".
> They were married for some years.

Naming things is difficult.

> (snip)
>> or Hurd if that's ready this year. <g>
>
> Heh, I've been waiting for years. Maybe someday! More recently I had
> half an eye on GuixSD too in case that got further with Hurd first.
> Perhaps that Linux works so well means reduces any need for Hurd.

Maybe everybody's so busy fixing symptoms that nobody's left to fix the
problems that cause them. What would I know, I just rode in on last
night's turnip truck. <g>