On Fri, 05 Aug 2011 22:00:43 -0400, Jim Henderson wrote:

> Yes, it's a choice of whether to rename the file or delete it

Agh, rename or copy.

Jim

Post a reply to this message

On 8/5/2011 18:59, Jim Henderson wrote:
> That of allowing files to be deleted while they're open.  I don't "think"
> that's a choice of the package manager, because it is in fact how *nix
> filesystems work, regardless of what the app thinks about it.

Well, yes, it allows files to be deleted while they're open.

"thankfully, package updates write a new file and rename it over the old 
name, leaving our open copy the only remaining reference to the old name."

That's the only place where he makes a distinction, and that's what I'm 
talking about. As I demonstrated elsewhere, it's a choice of the package 
manager whether to write a new file and rename it, or overwrite the old 
file, which is what he's talking about here.

> I guess we'll have to disagree on it.  I read his description and found
> that it made no sense at all, and I'm not exactly a newbie to Linux....

OK. It made perfect sense to me, and I'm not exactly a newbie to Linux *or* 
Unix.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/5/2011 19:00, Jim Henderson wrote:
> On Fri, 05 Aug 2011 14:19:32 -0700, Darren New wrote:
>
>> It's the choice of the
>> package manager to use one technique over the other, not the choice of
>> the file system.
>
> Yes, it's a choice of whether to rename the file or delete it.  That's
> not really my point.

OK. Then I'm not seeing your point. What statement do you think is actually 
incorrect?  I must be missing something, because you're not the only person 
who has told me there are incorrect assertions in the article, but I've not 
gotten anyone else to actually say what they are either, other than arguing 
that Linux's package management isn't "inferior".

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/5/2011 20:24, Darren New wrote:
> Well, yes, it allows files to be deleted while they're open.

Or, more technically, unlinked. The files obviously don't get deleted.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On Fri, 05 Aug 2011 20:25:59 -0700, Darren New wrote:

> On 8/5/2011 19:00, Jim Henderson wrote:
>> On Fri, 05 Aug 2011 14:19:32 -0700, Darren New wrote:
>>
>>> It's the choice of the
>>> package manager to use one technique over the other, not the choice of
>>> the file system.
>>
>> Yes, it's a choice of whether to rename the file or delete it.  That's
>> not really my point.
> 
> OK. Then I'm not seeing your point. What statement do you think is
> actually incorrect?  I must be missing something, because you're not the
> only person who has told me there are incorrect assertions in the
> article, but I've not gotten anyone else to actually say what they are
> either, other than arguing that Linux's package management isn't
> "inferior".

"one distinction between "lame port of a Windows app" and "real Linux 
software" is exactly whether you distribute as a tarball or as a package."

Factually incorrect, as I said, ask anyone using Slackware what they 
think of that statement and they'll laugh you out of the room.

"Secondly, and more importantly, we knew that regardless of what we did 
for Google Chrome the Linux distros would attempt to stuff Chromium into 
their package manager even when they know it breaks the app, much like 
they've done to Firefox."

Factually incorrect, since package management systems that use RPM or DEB 
allow for the creation of packages that won't install if a conflicting 
package is installed.

"Now that I've summarized it in these terms it sounds a little 
depressing, but there it is"

Factually incorrect, because he got the previous two statements 
completely wrong.

Jim

Post a reply to this message

On 8/5/2011 21:20, Jim Henderson wrote:
 > "one distinction between "lame port of a Windows app" and "real Linux
 > software" is exactly whether you distribute as a tarball or as a package."
 >
 > Factually incorrect, as I said, ask anyone using Slackware what they
 > think of that statement and they'll laugh you out of the room.

Does a tarball on Slackware actually track dependencies? I think any general 
statement you make about Linux is going to be wrong in at least one 
distribution. Plus, that's one distinction. He's obviously talking about the 
distros that actually have packages.

 > Factually incorrect, since package management systems that use RPM or DEB
 > allow for the creation of packages that won't install if a conflicting
 > package is installed.

I think making a Chrome update package that won't install if Chrome is 
already present would be counterproductive.  What do you think the 
"conflicting package" would be?


-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

Le 06/08/2011 07:20, Darren New nous fit lire :
> Does a tarball on Slackware actually track dependencies?

well, it won't compile if the dependencies is not already installed. ;-)

I remember trying to compile gnome on a slackware (old gnome, old
slackware,... old time). It was a bit a game of "try and error/again" as
there was a lot of modules, with no clear order described.

Gentoo is also source-based, and it does track dependencies in its
packages system. It's easier that slackware, as long as you are ok to
follow their option/use system.

(but it can be complex if you want option A for some packages and not-A
for some others... which have a common package!)

Post a reply to this message

On 8/5/2011 22:39, Le_Forgeron wrote:
> Le 06/08/2011 07:20, Darren New nous fit lire :
>> Does a tarball on Slackware actually track dependencies?
>
> well, it won't compile if the dependencies is not already installed. ;-)

Well, yes. The trick is (A) keeping things up to date, and (B) not 
uninstalling dependencies for code that's installed. :-)

I mean, there were lots of UNIX systems without any sort of package manager. 
That's what RedHat fixed.  So I'd say, yes, sure, a "real" Linux program is 
available as a package.  If your Linux doesn't use packages, then obviously 
you don't use the package version of the program.

> (but it can be complex if you want option A for some packages and not-A
> for some others... which have a common package!)

That was always the problem I ran into, yes. Or conflicting versions of DLLs 
both referenced without version numbers.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On Fri, 05 Aug 2011 22:20:09 -0700, Darren New wrote:

> On 8/5/2011 21:20, Jim Henderson wrote:
>  > "one distinction between "lame port of a Windows app" and "real Linux
>  > software" is exactly whether you distribute as a tarball or as a
>  > package."
>  >
>  > Factually incorrect, as I said, ask anyone using Slackware what they
>  > think of that statement and they'll laugh you out of the room.
> 
> Does a tarball on Slackware actually track dependencies? I think any
> general statement you make about Linux is going to be wrong in at least
> one distribution. Plus, that's one distinction. He's obviously talking
> about the distros that actually have packages.

It's been a long time since I installed a package on Slack, so I don't 
know how they track dependencies.  But my point is that he says that 
distributing a tarball doesn't make it "real Linux software", but a "Lame 
port of a Windows app".  There are plenty of software packages for Linux 
that are only distributed as a tarball.  Truecrypt comes to mind, 
actually.  One might argue that there is also a Windows version of 
Truecrypt so it might qualify as a "lame port of a Windows app" until one 
realizes that architecturally, the Linux version is quite different 
(doesn't require a system-level device driver on Linux, but it does on 
Windows - for example).

If he's "obviously talking about the distros that actually have 
packages", then the point becomes meaningless because it's self-
referential.

>  > Factually incorrect, since package management systems that use RPM or
>  > DEB allow for the creation of packages that won't install if a
>  > conflicting package is installed.
> 
> I think making a Chrome update package that won't install if Chrome is
> already present would be counterproductive.  What do you think the
> "conflicting package" would be?

Chromium, which is what he's talking about.  Chromium is different from 
Chrome.

Jim

Post a reply to this message

On 8/6/2011 12:29, Jim Henderson wrote:
> distributing a tarball doesn't make it "real Linux software",

No he doesn't. He says that's one way you can tell. And obviously he's not 
speaking technically. I.e., I think you're reading way too much into the 
part that talks about the motivation for making it work with Linux package 
managers.

> If he's "obviously talking about the distros that actually have
> packages", then the point becomes meaningless because it's self-
> referential.

I disagree. There are lots of lame ports of Windows software that's 
distributed as a tarball for Ubuntu, for example.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message