From: Juerd
Date: 13:21 on 23 Apr 2005
Subject: Upgrading without central packaging
So I've had a Mac for a month now. And there's a new version of Firefox
that has some bug and security fixes, so I thought it'd be wise to
upgrade.
Under Debian, I'd also upgrade the rest of my system, just because it's
just as easy and doesn't take a lot more time. I would type two simple
commands and it would get me new versions of everything, probably
including Firefox:
apt-get update
apt-get dist-upgrade
But - with my shiny new Mac Mini, I have to upgrade Firefox the same way
I installed it, and I recall not liking that. Again, with Debian, it'd
have been just one simple command:
apt-get install firefox
Which downloads and installs all without my intervention. Instead, I
have to:
1. start a browser (in this case Firefox)
2. enter a URL (getfirefox.com)
3. click a link (download)
4. wait for the download to finish
5. double click an icon (dmg)
6. drag another icon to the Applications folder
7. confirm that I want to replace the old one
8. close the Finder window again
9. select two icons (dmg and mounted volume)
10. drag them to Trash
And after all that hard labour, all that's upgraded is just one program!
There's not even something that can tell me what updates are available
for the many programs I have installed the past month, so I have to
check that manually too.
As far as I am concerned, Apple's Mac OS X and Microsoft's Windows XP
are not yet ready for the Desktop. This is too much hard and confusing
work to confront newbies with. I'm lucky to be a geek and understand the
entire 10 step procedure!
Juerd
From: peter (Peter da Silva) Date: 14:16 on 23 Apr 2005 Subject: Re: Upgrading without central packaging > apt-get install firefox As I noted in another thread, I see that as a solution to a problem that doesn't need to exist. Installing and upgrading applications in a traditional UNIX environment has become quite hard. So a lot of effort has been put into making the hard easy. For different reasons, the same is true on Windows, and they've come up with a different way to make the hard thing easy. And on Mac OS, installing applications has always been easy. But the people writing cross-platform applications have spent a lot of time and effort coming up with packaging schemes and installers, and so have transferred both of them over to Mac OS X. Please, don't do that. > 1. start a browser (in this case Firefox) > 2. enter a URL (getfirefox.com) Try http://macupdate.com/ instead. You can update the rest of the apps you use at the same time. > 3. click a link (download) > 4. wait for the download to finish > 5. double click an icon (dmg) Click on the name in the download window. > 6. drag another icon to the Applications folder And you get to say WHERE you want it, it doesn't just vanish into the dark forest of /usr. So when you want to sync up your Mac at work with the software on your Mac at home you just rsync --rsh=ssh home.example.com::/Local /Local > 7. confirm that I want to replace the old one > 8. close the Finder window again Click on the "eject" button next to the volume name. > 9. select two icons (dmg and mounted volume) > 10. drag them to Trash Drag the DMG to "/Local/Installed" so you have a clean copy, and when you clicked eject you unmounted the DMG and closed the window. > And after all that hard labour, all that's upgraded is just one program! http://macupdate.com/ or http://versiontracker.com/ I prefer macupdate, Versiontracker is a bit tarpit-ish. > As far as I am concerned, Apple's Mac OS X and Microsoft's Windows XP > are not yet ready for the Desktop. This is too much hard and confusing > work to confront newbies with. I'm lucky to be a geek and understand the > entire 10 step procedure! The 8-step procedure is easier for newbies than "apt-get install firefox".
From: Michael G Schwern Date: 14:53 on 23 Apr 2005 Subject: Re: Upgrading without central packaging On Sat, Apr 23, 2005 at 08:16:32AM -0500, Peter da Silva wrote: > > apt-get install firefox > > As I noted in another thread, I see that as a solution to a problem > that doesn't need to exist. Installing and upgrading applications in a > traditional UNIX environment has become quite hard. So a lot of effort > has been put into making the hard easy. For different reasons, the same > is true on Windows, and they've come up with a different way to make > the hard thing easy. I think you miss the point. I share Juerd's hate for the Mac because I, too, am I Debian user. I see it even clearer because I use fink which gives me apt for *some* of my Mac software. Another perfect example is the CPAN shell for Perl modules vs, say, keeping your Java libraries up to date. Its not about making a single piece of software easy to install, that's been done, its about making the entire system easy to keep up-to-date. Once you can easily check what's up-to-date you no longer have people using ancient, buggy versions of software just because they don't want/care about doing the periodic chore of manually checking all their software. "Update all the software on my machine" should be one command. I don't care how it does it, just do it. I don't want to have to go look up and download each individual piece of software. Sites like macupdate and versiontracker just reduce the constant on an O(n) operation (where n == the number of apps installed) but it remains an O(n) task for the user. It should be O(1). Most Linuxen, FreeBSD and Perl make it O(1). Those systems all existed before OS X did. Apple should be able to figure it out. No complex packaging system or registry is required because Apple already has such a system, the .app bundle. It could have been something as simple as an extra file in the .app directory describing where to check for and download the latest version. The details of this doesn't matter, its a long since solved problem. Hell, if Apple were smart they'd provide a mirror for everybody who wanted one, like Debian and CPAN do, so you don't even have to worry about the author's download site going down. A program then searches all .apps and .pkg receipts for these, checks each one against the named site and if an upgrade is necessary it downloads, mounts and copies the app. Even if it didn't do the copy step--just check for what's out of date, download the new versions and mount them--this would be a Great Leap Forward in maintainability. Make it part of Software Update. Its a very rote task. Computers are for rote tasks. The most hateful software is that which turns users into click-monkeys for computers.
From: peter (Peter da Silva) Date: 15:50 on 23 Apr 2005 Subject: Re: Upgrading without central packaging > I think you miss the point. I share Juerd's hate for the Mac because I, too, > am I Debian user. I see it even clearer because I use fink which gives me > apt for *some* of my Mac software. Another perfect example is the CPAN > shell for Perl modules vs, say, keeping your Java libraries up to date. Keeping MY java libraries up to date involves clicking on "Software Update" once in a while. CPAN is another example of a very powerful solution to a problem that should be avoided. I have a lot of hate for the way CPAN works: it's aggressive, and assumes it's the whole world. It forces you to stay up to date by taking over. Whenever I've used it it's pulled down layers and layers and layers of Perl scripts that depend on Perl scripts that depend on Perl scripts, most of which dependencies aren't really necessary. Dependencies are bad. Tools to resolve dependencies are only good when the dependencies are necessary. Tools to MANAGE dependencies and let you see what they are so you can avoid them when you don't need them are rare. Hell, it's often hard to even SEE what the dependencies are, particularly in open source software. So what I see is a perl script to do something useful, the guy who used it wanted to do something and there was a CPAN module that did a lot of other stuff but also seemed to be a bit easier way of doing whatever he wanted than writing a couple dozen lines of code himself. So he uses it. He never sees that that module pulls in 20 others, and then it says "SillyJokes::Unicorns needs Perl5.0003.34 and you're using perl5.0003.16" and the next thing I know it's pulled down perl5.0004.12, and built that... HATE So I go in to the original program, and find that it's using some XML parser to grep a fixed format web page for a chunk of text that doesn't even include any HTML, and I replace it with a regexp, and the resulting code is 20 times faster. HATE CPAN is a snare for the programmer. It's hiding great nests of evil that should not exist. > Its not about making a single piece of software easy to install, that's > been done, its about making the entire system easy to keep up-to-date. > Once you can easily check what's up-to-date you no longer have people using > ancient, buggy versions of software just because they don't want/care about > doing the periodic chore of manually checking all their software. That's a good thing, but it's not the only thing. Most commercial operating systems and many applications have mechanisms to automatically update themselves. I ALWAYS turn these off sooner or later, because all too often I have had the "new, improved" version break things. Developers do stupid things, sometimes. They remove functionality. They break functionality they don't care about. They change configuration files. They don't necessarily want the same thing out of their software that I do. Would you want to be automatically updated to something like Netscape 6? What if you want to keep the functionality that was dropped in later versions of Gnomeapps, and you're not a geek who can edit the config files? > "Update all the software on my machine" should be one command. It is on FreeBSD. I never use it. > No complex packaging system or registry is required because Apple already > has such a system, the .app bundle. It could have been something as simple > as an extra file in the .app directory describing where to check for and > download the latest version. The version number is already there in every .app directory. There's already third party tools that promise to take care of you, using their own databases or the ones at MacUpdate or Versiontracker. I think Macupdate sells one. Apple has made a painful task trivial, without forcing people like me to work like people like you, AND there's software for people like you. It's a MUCH less hateful solution than Debian or CPAN or even FreeBSD Ports.
From: Michael G Schwern Date: 17:15 on 23 Apr 2005 Subject: Re: Upgrading without central packaging On Sat, Apr 23, 2005 at 09:50:41AM -0500, Peter da Silva wrote: > Dependencies are bad. Tools to resolve dependencies are only good when the > dependencies are necessary. Tools to MANAGE dependencies and let you see > what they are so you can avoid them when you don't need them are rare. Hell, > it's often hard to even SEE what the dependencies are, particularly in open > source software. Dependencies might be bad but ya know what's worse? Everybody reinventing the wheel 20 times over and each getting it wrong in subtly different ways AND hard coding their bug into the software. Oh look, ANOTHER half assed regex-based HTML parser that breaks when you throw anything complex at it. Here's one that tries to send mail with /usr/lib/sendmail. Oh look, this one gets the leap year calculation wrong. This one can only one handle one date format. Oh goody, ANOTHER templating language to learn! I want to patch the tests on this one but its using some crappy home-rolled testing library. Great, ANOTHER POD parser that gets tripped up by complex POD. I've seen it all. I hate it. Modules and dependencies suck less. If nothing else at least you only have to install them once, its automatable and the bugs are in one place. They introduce new hate but overall hate is reduced. > So what I see is a perl script to do something useful, the guy who used it > wanted to do something and there was a CPAN module that did a lot of other > stuff but also seemed to be a bit easier way of doing whatever he wanted than > writing a couple dozen lines of code himself. So he uses it. He never sees > that that module pulls in 20 others, and then it says "SillyJokes::Unicorns > needs Perl5.0003.34 and you're using perl5.0003.16" and the next thing I > know it's pulled down perl5.0004.12, and built that... > > HATE The problem of the CPAN shell pulling down perl been fixed for quite some time. I hated it, too. > So I go in to the original program, and find that it's using some XML parser > to grep a fixed format web page for a chunk of text that doesn't even include > any HTML, and I replace it with a regexp, and the resulting code is 20 times > faster. > > HATE This is partially a consequence of Perl's weak dependency system. You depend on something or you don't. RPM has a similar problem. A new system is being introduced via Module::Build with a much more rich dependency system (modeled on uncoincidentally dpkg) including things like "recommends" which lets you avoid the problem of installing the universe just because you *might* need something. Similar to the way you can very easily install something like XEmacs under Debian without having X. This system is not all in place yet. Perl has the additional issue that we've traditionally avoided bundling modules together into great big wads like Java does. It boils down to the shared vs static libraries debate which I'm not going to get into. At least now the tools exist to wad a Perl application's dependencies together using PAR. All its implementation hate aside, its the only language that's usefully solved the problem of automatic dependency installation and upgrade at the language level! Most languages don't even try or they have some crappy web site (RAA, Vaults of Pernasis, CodeZoo) or they just smash as much as they can into the base distribution (Java, PHP) or they let individual operating system vendors figure it out (C). Anyhow, that's Perl-specific hates. We're talking about Apple. > Most commercial operating systems and many applications have mechanisms to > automatically update themselves. I ALWAYS turn these off sooner or later, > because all too often I have had the "new, improved" version break things. > > Developers do stupid things, sometimes. They remove functionality. They break > functionality they don't care about. They change configuration files. They > don't necessarily want the same thing out of their software that I do. > > Would you want to be automatically updated to something like Netscape 6? > What if you want to keep the functionality that was dropped in later versions > of Gnomeapps, and you're not a geek who can edit the config files? If the new version sucks then reinstall the old version. What's worse? Manually checking and upgrading 100 pieces of software every week/month? Or doing it automatically and having to rollback one application every once in a while? Or maybe you just let everything get dusty. Keep in mind this is a desktop machine, not a server. What's going to consume more of your time in the long run? And if you don't like the new version is fucked, what's the alternative? Use the old version forever? Do you still use Netscape 4? No, if newer versions continue to be fucked you're going to dump the app entirely and switch to something else. Looking at this MacUpdate Desktop thing it looks like it has per-version ratings so you can get an idea if its going to be a lousy update before you let it update. You can't avoid upgrading forever. This is hateful but it is less hateful than dealing with having to work with and write for ancient versions of software. > > No complex packaging system or registry is required because Apple already > > has such a system, the .app bundle. It could have been something as simple > > as an extra file in the .app directory describing where to check for and > > download the latest version. > > The version number is already there in every .app directory. There's already > third party tools that promise to take care of you, using their own databases > or the ones at MacUpdate or Versiontracker. I think Macupdate sells one. I paid $1500 for this machine and operating system and (if I actually paid for upgrades) $140 for each OS upgrade. I shouldn't have to pay another $40/year for a basic packaging system. A $300 PC with a free OS can manage it. Why not Apple? Yes, I expect to get my money's worth. Otherwise, that MacUpdate Desktop looks like what I want. Thank you. > Apple has made a painful task trivial, without forcing people like me to work > like people like you, AND there's software for people like you. It's a MUCH > less hateful solution than Debian or CPAN or even FreeBSD Ports. There's no forcing you to work like me. You can allow automation without forcing automation. The dmgs would still be downloadable by hand if you really wanted to, same as they are now. Same as how you can grab all the stuff provided by Software Update by hand if you really wanted to do that. I miscast the order of the upgrade algorithm. Currently it is not O(n) (ie. worst case is N) it is omega(n). The BEST case is n. I want theta(1) with O(n). Average case upgrading should be one step. Worst (or in your case, desired) case its n. Which is, I guess, the point. If you don't want to do automatic upgrades fine, but don't stop me from doing it. And especially don't let me have a taste (Software Update) and then not do it for everything.
From: Matt McLeod Date: 17:27 on 23 Apr 2005 Subject: Re: Upgrading without central packaging Michael G Schwern wrote: > Modules and dependencies suck less. If nothing else at least you only > have to install them once, its automatable and the bugs are in one place. This does rather assume that you've got lots of dependency-handling cruft in place, though. Which, at work, we do not have -- we're a combined Solaris/Tru64 shop with our own custom packaging stuff (don't ask), which means that every damned module some random bit of Perl requires has to be packaged by hand. No CPAN.pm. The result is that whenever I need some bit of functionality from a module we don't already have installed, I have to ask myself whether it's worth the hassle of packaging it (and all its dependencies) to avoid writing some stuff of my own. Works out around a 50:50 split. As it happens I've got plenty of hate for our local packaging system (it has no concept of dependencies, and bootstrapping a new host is a real pain in the arse) too, but I've spent too many years working in not-Linux shops to buy into the huge tangle of dependencies in a typical Perl application being a good thing. Of course, it's even worse when it's some random small X11 GUI thing you want to play with and it drags in all of fucking Gnome. Matt
From: peter (Peter da Silva) Date: 22:49 on 23 Apr 2005 Subject: Re: Upgrading without central packaging > Of course, it's even worse when it's some random small X11 GUI thing > you want to play with and it drags in all of fucking Gnome. Oh yes, oh yes, oh yes. I don't want ANY gnome or KDE on my box, and when I switched from FreeBSD to Mac OS I still had multiple copies of some of that crap because at some point they made some incompatible API changes and so different apps depended on different versions. All together now, feel the hate!
From: David Champion Date: 23:25 on 23 Apr 2005 Subject: Re: Upgrading without central packaging * On 2005.04.23, in <20050423214914.37014413C6@xxxxxxx.xx.xxxxxxx.xxx>, * "Peter da Silva" <peter@xxxxxxx.xxx> wrote: > > of some of that crap because at some point they made some incompatible > API changes and so different apps depended on different versions. Right there. That's the #1 reason why I never, never want my software maintenance to depend on "apt-get upgrade everything you see". But even if that's fixed in some far-off dreamy version of $crackheaded_os_of_the_decade, none of you will ever convince me that one's entire OS ought to work this way. Nor one's entire perl, for that matter. There are too many sources of authority for the dependencies to be managed in one clearinghouse. That said, I'm moderately happy with Software Update. It only updates things within its own domain of authority, and that's fine with me. A preference pane I could open up to find out what's new among all my installed applications, and choose which ones to update today, that would be nice too. But "be smart for me"? No, thanks. I've seen this scenario: something had to start working, I didn't have time to mess around, I needed results, but I also needed to update a few packages on my Debian system to get there. It's rather infuriating to do an update and find that the system's dependency tracker has decided to swap out 70% of your OS, leaving fragments behind, or leaving multiple versions behind, or removing applications I used that no longer had dependencies supplied by the current set of provisions.... and to still need to get work done ASAP. I'll take linux kids whinging over how omfg 3 years out of date my xyz is any day over that. Cause you know, my xyz still works. And half of what you'd have me install, I've never heard of and will never find a use for. I miss filesystem versioning. Metadata in the filesystem or not, at least it was harder to produce an excuse not to use it. Unix would still have found a way to make it useless, though. The #! should have died in a dark corner decades ago, but nobody ever met the versioning requirements to kill it.
From: peter (Peter da Silva) Date: 15:32 on 24 Apr 2005 Subject: Re: Upgrading without central packaging > I miss filesystem versioning. Versioning is fine. I prefer the "snapshot" model to the VMS style "file version" model... it's like the differnce between SCCS/RCS and CVS... but it's a whole separate issue than metadata. FreeBSD now has snapshots. Hopefully that will spread to other BSDs like Mac OS X (if Apple would pull their head out and dump HFS+ in the toxic waste bin... all the kewl stuff they "need" in HFS+ can be done at the vnode layer, honest, but let's not get into my hate for UNIX file systems that are not at least as good as UFS/FFS), and maybe even Linux eventually. I like the way NetApp exposes snapshots, personally.
From: Zack Weinberg Date: 17:46 on 23 Apr 2005 Subject: Sending mail (was Re: Upgrading without central packaging) Michael G Schwern <schwern@xxxxx.xxx> writes: > Here's one that tries to send mail with /usr/lib/sendmail. Programs that *don't* send mail with /usr/lib/sendmail (yeah, yeah, these days /usr/sbin/sendmail) are hateful. /usr/lib/sendmail has a correct implementation of SMTP, unlike half the programs that try to do it themselves. How many people have written their own half-assed SMTP senders when they *didn't have to*, because there was a perfectly good /usr/lib/sendmail *right there*? /usr/lib/sendmail has been correctly configured for the local mail setup. How many times do I have to explain to yet another program that no, it is not to try to connect to mail.$ISP.com on port 25 and send passwords in cleartext? zw
From: Chris Devers Date: 18:19 on 24 Apr 2005 Subject: Re: Sending mail (was Re: Upgrading without central packaging) On Sat, 23 Apr 2005, Zack Weinberg wrote: > Programs that *don't* send mail with /usr/lib/sendmail (yeah, yeah, > these days /usr/sbin/sendmail) are hateful. Including, for example, everything that sends mail on Windows? Or everything on a platform (e.g. OSX) where the program at that location, which may or not be Sendmail-TM-brand-sendmail, is by default configured not to deliver, because mismanaged mail proxies are evil? And how about thosee non-Sendmail-TM-brand-sendmails, e.g. the ones set up by Postfix et al. Does the Hate cover those as well? So many ways to hate!
From: Daniel Pittman
Date: 00:48 on 25 Apr 2005
Subject: Re: Sending mail
On 25 Apr 2005, Chris Devers wrote:
> On Sat, 23 Apr 2005, Zack Weinberg wrote:
>
>> Programs that *don't* send mail with /usr/lib/sendmail (yeah, yeah,
>> these days /usr/sbin/sendmail) are hateful.
>
> Including, for example, everything that sends mail on Windows?
Oh, yes. I really hate that. If Windows came with a single standard
interface to sending email, like sendmail(1), life would be so much
better, because...
> Or everything on a platform (e.g. OSX) where the program at that
> location, which may or not be Sendmail-TM-brand-sendmail, is by default
> configured not to deliver, because mismanaged mail proxies are evil?
...you could chose to implement this. Alternately, you could do the
typical Microsoft solution of reacting to a virus making five hundred
queries of the address book by asking "Do you want to allow this" five
hundred times, in a row, with no way to avoid answering each one.[1]
> And how about thosee non-Sendmail-TM-brand-sendmails, e.g. the ones set
> up by Postfix et al. Does the Hate cover those as well?
In case you didn't notice, Postfix and almost all the other non-sendmail
brand sendmail systems provide sendmail(1) in the right location.
This is because Unix does have a standard way of sending mail. The
proliferation of writing sendmail(1) yourself, incorporate in your code,
but badly is something I lay at the feet of Windows.
Thanks of a system where that was the *best* way to achieve the result,
you bastards.
Daniel
Footnotes:
[1] Well, actually, my clients of the time usually powered off the
machine, since the soft power button still worked.
From: peter (Peter da Silva) Date: 01:02 on 25 Apr 2005 Subject: Re: Sending mail > Oh, yes. I really hate that. If Windows came with a single standard > interface to sending email, like sendmail(1), life would be so much > better, because... It does, it's called MAPI, and it's one of the few things I've found on Windows that involved third parties that are competing with Microsoft that really does work as advertised when it's actually set up. The problem is that you need to have at least one properly configured mail client to make it work. But once you do it you can (for example) have your Pocket PC use Netscape Communicator as its mail server.
From: peter (Peter da Silva) Date: 22:43 on 23 Apr 2005 Subject: Re: Upgrading without central packaging > > Dependencies are bad. Tools to resolve dependencies are only good when the > > dependencies are necessary. Tools to MANAGE dependencies and let you see > > what they are so you can avoid them when you don't need them are rare. Hell, > > it's often hard to even SEE what the dependencies are, particularly in open > > source software. > Dependencies might be bad but ya know what's worse? Everybody reinventing > the wheel 20 times over and each getting it wrong in subtly different ways > AND hard coding their bug into the software. Yep, that's why you need a tool a MANAGE dependencies, not just HIDE them. > All its implementation hate aside, its the only language that's usefully > solved the problem of automatic dependency installation and upgrade at the > language level! I'm waiting for that to seem like a good idea. > Anyhow, that's Perl-specific hates. We're talking about Apple. We're talking about hate. > If the new version sucks then reinstall the old version. How do you do that through the package system? > What's worse? Manually checking and upgrading 100 pieces of software every > week/month? Or doing it automatically and having to rollback one > application every once in a while? Or maybe you just let everything get > dusty. Keep in mind this is a desktop machine, not a server. I let everything get dusty. I upgrade stuff when I need to. It's amazing how much I don't need to. > And if you don't like the new version is fucked, what's the alternative? > Use the old version forever? If necessary. > Do you still use Netscape 4? No, but I'm sure glad that I didn't have to deal with 150 users automatically upgraded to Netscape 6, and instead I could test it and then when Netscape 7 was ready I could roll it out THEN. > You can't avoid upgrading forever. Why not? I know people who are still using Mac OS 7, 8, and 9. And the software that runs on their computers is pretty dusty. But it still does what they need. > This is hateful but it is less hateful > than dealing with having to work with and write for ancient versions of > software. And that attitude is why I don't want to let someone else tell me when to upgrade. Particularly in an environment where some of the dependencies are commercial and upgrading costs money. Particularly when (say) it's a lot easier to support Netscape 4 in a degraded but acceptable fashion than to support the latest IE with CSS pages. And "ancient versions" of MOST software doesn't even produce ANY work for developers because it's not programmable or is only programmed by the end-users. Like, say, most Mac software. > I paid $1500 for this machine and operating system and (if I actually paid > for upgrades) $140 for each OS upgrade. I shouldn't have to pay another > $40/year for a basic packaging system. Yeh, I get like that about commercial stuff I think should be in the OS. Like, say, an accelerated X server for a popular video card. But it costs money to develop drivers, so if you want it you have to pay for it. You know what? It costs money to track dependencies. This guy is doing it for $40 per year. Debian does it for free, but Debian's got a lot of resources he doesn't. Maybe Apple should have come up with a few more hooks for this, but they did at least provide enough to make it possible if not as easy as you want... and there's an awful lot of other missing APIs I'd like them to take care of first.
From: Michael G Schwern Date: 23:29 on 23 Apr 2005 Subject: Re: Upgrading without central packaging On Sat, Apr 23, 2005 at 04:43:49PM -0500, Peter da Silva wrote: > > Anyhow, that's Perl-specific hates. We're talking about Apple. > > We're talking about hate. You're right! Let me get back to hating. > > If the new version sucks then reinstall the old version. > > How do you do that through the package system? In Perl? You type the location of the older tarball in which, frankly, is hateful. Via apt you say "apt-get install package==x.y" which is ok I suppose. dselect an aptitude let you set a "hold" on a package so the system will not upgrade. At least the Debian tools give you a summary of everything they're going to install and upgrade before doing it. The CPAN shells don't. You have to find out halfway through that the thing you're installing needs Combust that has 15 dependencies. I know the infrastructure reasons why but it doesn't mean I can't hate it. > > Do you still use Netscape 4? > > No, but I'm sure glad that I didn't have to deal with 150 users automatically > upgraded to Netscape 6, and instead I could test it and then when Netscape 7 > was ready I could roll it out THEN. If you're supporting an office then you have a local mirror of the software update server and point everything at that. At least then you don't have to log into every machine and install new software (HATE) or reimage with Ghost (HATE) or have everyone use a shared application partition (the network's down, nobody can do anything. HATE) or in other ways micromanage your user's desktop toaster. > > You can't avoid upgrading forever. > > Why not? I know people who are still using Mac OS 7, 8, and 9. And the > software that runs on their computers is pretty dusty. But it still does what > they need. Whole new class of hate: supporting MacOS Classic. Its hard enough having to deal with Windows 9x, Windows NT, VMS and all the scattered Unixen out there, at least they're on speaking terms with POSIX. MacOS Classic does EVERYTHING differently and in 1988 this might have been interesting but in 2005 its just embarassing. I would rather (and do) code for VMS than MacOS Classic and I HATE VMS. > > This is hateful but it is less hateful > > than dealing with having to work with and write for ancient versions of > > software. > > And that attitude is why I don't want to let someone else tell me when to > upgrade. Particularly in an environment where some of the dependencies are > commercial and upgrading costs money. So who's shelling out $140 for 10.4? How long to you think it will be before it becomes impossible to find 10.3 software? Hate. But 10.1 and 10.2 were so hateful I can understand why folks dropped it like a hot iron.
From: peter (Peter da Silva) Date: 02:11 on 24 Apr 2005 Subject: Re: Upgrading without central packaging > Whole new class of hate: supporting MacOS Classic. Its hard enough having > to deal with Windows 9x, Windows NT, VMS and all the scattered Unixen out > there, at least they're on speaking terms with POSIX. MacOS Classic does > EVERYTHING differently and in 1988 this might have been interesting but in > 2005 its just embarassing. I would rather (and do) code for VMS than > MacOS Classic and I HATE VMS. Which brings us back to the "everything is really UNIX" meme. > So who's shelling out $140 for 10.4? I'm shelling out $70 for it. > How long to you think it will be before > it becomes impossible to find 10.3 software? I'm still running 10.2 on some of mine. > Hate. But 10.1 and 10.2 were > so hateful I can understand why folks dropped it like a hot iron. 10.1, yes. 10.2 was in some ways (Finder, [insert HATE here]) better than 10.3.
From: Michael G Schwern Date: 02:58 on 24 Apr 2005 Subject: Re: Upgrading without central packaging On Sat, Apr 23, 2005 at 08:11:01PM -0500, Peter da Silva wrote: > > Hate. But 10.1 and 10.2 were > > so hateful I can understand why folks dropped it like a hot iron. > > 10.1, yes. > > 10.2 was in some ways (Finder, [insert HATE here]) better than 10.3. Uggg, 10.2's integration with Unix was just appalling. Half the standard Unix administrative commands were either missing or worse weren't integrated with the NetInfo way of doing things so they would silently alter the standard Unixy files but have no effect. And don't get me started about tcsh being the default. *shudder* At least OSXGNU fixed the most glaring oversights like groupadd and useradd.
From: David Champion Date: 04:27 on 24 Apr 2005 Subject: Re: Upgrading without central packaging * On 2005.04.23, in <20050424015853.GA2335@xxxxxxxx.xxxxxxx.xxx>, * "Michael G Schwern" <schwern@xxxxx.xxx> wrote: > > Uggg, 10.2's integration with Unix was just appalling. Half the standard > Unix administrative commands were either missing or worse weren't integrated > with the NetInfo way of doing things so they would silently alter the > standard Unixy files but have no effect. And don't get me started about > tcsh being the default. *shudder* > > At least OSXGNU fixed the most glaring oversights like groupadd and useradd. Ha. Now you're giving me NeXTStep 2 vs. 3 flashbacks. You want appalling? I'll take absence of silly group administration commands any time over missing uname and cuserid. And at least those could be easily faked. There were worse oversights I've repressed. Still, either way, it was a beautiful system to *use*. There aren't nearly so many things unbearably wrong with Darwin, but they've managed to make the UI substantially more aggravating. Ebb and flow.
From: peter (Peter da Silva) Date: 04:29 on 24 Apr 2005 Subject: Re: Upgrading without central packaging > > 10.2 was in some ways (Finder, [insert HATE here]) better than 10.3. > Uggg, 10.2's integration with Unix was just appalling. Half the standard > Unix administrative commands were either missing or worse weren't integrated > with the NetInfo way of doing things so they would silently alter the > standard Unixy files but have no effect. Ah, it never occurred to me to try and bypass netinfo. But then I have a Nextstation. > And don't get me started about tcsh being the default. *shudder* Don't get me started about bash being the default either. Or about nvi being replaced by vim. HATE
From: David King Date: 08:16 on 24 Apr 2005 Subject: Re: Upgrading without central packaging > Ah, it never occurred to me to try and bypass netinfo. But then I have > a > Nextstation. It isn't necessarily something on purpose. Some tools (or me, sometimes) assume that they can view/edit /etc/passwd (hatefully, indeed), or that /etc/exports can be reliably parsed, and since you think, "Hey, it's unix, right?" they'll work. Speaking of which, anybody know some good ways to have NIS and netinfo interact well, or at all?
From: peter (Peter da Silva) Date: 15:38 on 24 Apr 2005 Subject: Re: Upgrading without central packaging > If you're supporting an office then you have a local mirror of the software > update server and point everything at that. At least then you don't have > to log into every machine and install new software (HATE) or reimage with > Ghost (HATE) or have everyone use a shared application partition (the > network's down, nobody can do anything. HATE) or in other ways micromanage > your user's desktop toaster. What I do is rsync /usr/local around. I have mostly tried to treat my user's desktop toaster as an x-terminal that happens to run some really awful GUI based software they need for stupid political reasons. You know, stuff like Orifice and Goats and Visual Make and the appropriately named SAP. That's out of my hands now, I just get people asking me what I recommend. > Whole new class of hate: supporting MacOS Classic. Don't. If someone wants to use it then you let them sink or swim. Usually they want to use it because they know how to swim in it. If they sink, it's cheaper to upgrade them to OS X than to spend the time supporting them. Unless you have no budget, like it's charity work, but that's good for your soul.
From: Aaron J. Grier Date: 01:12 on 28 Apr 2005 Subject: Re: Upgrading without central packaging On Sat, Apr 23, 2005 at 09:15:12AM -0700, Michael G Schwern wrote: > Dependencies might be bad but ya know what's worse? expanding dependencies. like government, they never seem to get smaller. there's a nifty tool in pkgsrc/ports called pkgdepgraph that traces through the (known registered) dependencies and spits out a directed graph to graphviz. it always leaves me shaking my head.
From: Michael G Schwern Date: 01:36 on 28 Apr 2005 Subject: Re: Upgrading without central packaging On Wed, Apr 27, 2005 at 05:12:52PM -0700, Aaron J. Grier wrote: > On Sat, Apr 23, 2005 at 09:15:12AM -0700, Michael G Schwern wrote: > > Dependencies might be bad but ya know what's worse? > > expanding dependencies. like government, they never seem to get > smaller. > > there's a nifty tool in pkgsrc/ports called pkgdepgraph that traces > through the (known registered) dependencies and spits out a directed > graph to graphviz. it always leaves me shaking my head. Does BSD ports have a concept of a "recommends"? "Its not required that you install this but it sure would be useful". ie. "perl recommends perl-documentation". Any packaging system which does not is worthy of hate. This includes, but is not limited to, RPM and CPAN (as currently implemented). Debian has things so well sliced up that perl-base depends simply on a grand total of libc6 which in turn depends on libdb1. Everything else is "recommended" or "suggested", even the core modules and documentation.
From: Aaron J. Grier Date: 19:14 on 29 Apr 2005 Subject: Re: Upgrading without central packaging On Wed, Apr 27, 2005 at 05:36:13PM -0700, Michael G Schwern wrote: > Does BSD ports have a concept of a "recommends"? "Its not required > that you install this but it sure would be useful". ie. "perl > recommends perl-documentation". Any packaging system which does not > is worthy of hate. no recommends. but there's even bigger things to hate about pkgsrc.
From: Juerd Date: 16:30 on 23 Apr 2005 Subject: Re: Upgrading without central packaging Michael G Schwern wrote (crammed together here) 2005-04-23 6:53 (-0700): >Ithinkyoumissthepoint.IshareJuerd'shatefortheMacbecauseI,too,amIDebianu >ser.IseeitevenclearerbecauseIusefinkwhichgivesmeaptfor*some*ofmyMacsoft >ware.AnotherperfectexampleistheCPANshellforPerlmodulesvs,say,keepingyou >rJavalibrariesuptodate.Itsnotaboutmakingasinglepieceofsoftwareeasytoins >tall,that'sbeendone,itsaboutmakingtheentiresystemeasytokeepup-to-date.O >nceyoucaneasilycheckwhat'sup-to-dateyounolongerhavepeopleusingancient,b >uggyversionsofsoftwarejustbecausetheydon'twant/careaboutdoingtheperiodi >cchoreofmanuallycheckingalltheirsoftware."Updateallthesoftwareonmymachi >ne"shouldbeonecommand.Idon'tcarehowitdoesit,justdoit.Idon'twanttohaveto >golookupanddownloadeachindividualpieceofsoftware.Siteslikemacupdateandv >ersiontrackerjustreducetheconstantonanO(n)operation(wheren==thenumberof >appsinstalled)butitremainsanO(n)taskfortheuser.ItshouldbeO(1).MostLinux >en,FreeBSDandPerlmakeitO(1).ThosesystemsallexistedbeforeOSXdid.Applesho >uldbeabletofigureitout.Nocomplexpackagingsystemorregistryisrequiredbeca >useApplealreadyhassuchasystem,the.appbundle.Itcouldhavebeensomethingass >impleasanextrafileinthe.appdirectorydescribingwheretocheckforanddownloa >dthelatestversion.Thedetailsofthisdoesn'tmatter,itsalongsincesolvedprob >lem.Hell,ifAppleweresmartthey'dprovideamirrorforeverybodywhowantedone,l >ikeDebianandCPANdo,soyoudon'tevenhavetoworryabouttheauthor'sdownloadsit >egoingdown.Aprogramthensearchesall.appsand.pkgreceiptsforthese,checksea >choneagainstthenamedsiteandifanupgradeisnecessaryitdownloads,mountsandc >opiestheapp.Evenifitdidn'tdothecopystep--justcheckforwhat'soutofdate,do >wnloadthenewversionsandmountthem--thiswouldbeaGreatLeapForwardinmaintai >nability.MakeitpartofSoftwareUpdate.Itsaveryrotetask.Computersareforrot >etasks.Themosthatefulsoftwareisthatwhichturnsusersintoclick-monkeysforc >omputers. Schwern++ Juerd
From: Robert G. Werner Date: 22:02 on 23 Apr 2005 Subject: Re: Upgrading without central packaging Michael G Schwern wrote: [snip] > A program then searches all .apps and .pkg receipts for these, checks each > one against the named site and if an upgrade is necessary it downloads, > mounts and copies the app. Even if it didn't do the copy step--just check > for what's out of date, download the new versions and mount them--this would > be a Great Leap Forward in maintainability. Make it part of Software Update. > > Its a very rote task. Computers are for rote tasks. The most hateful > software is that which turns users into click-monkeys for computers. > > That's a really great idea!!! Almost sounds like a manifesto rather than hate!!!
From: Michael G Schwern Date: 22:41 on 23 Apr 2005 Subject: Re: Upgrading without central packaging On Sat, Apr 23, 2005 at 02:02:50PM -0700, Robert G. Werner wrote: > That's a really great idea!!! Almost sounds like a manifesto rather > than hate!!! Since when can't manifestos not be hate filled?
From: Robert G. Werner Date: 23:50 on 23 Apr 2005 Subject: Re: Upgrading without central packaging Michael G Schwern wrote: > On Sat, Apr 23, 2005 at 02:02:50PM -0700, Robert G. Werner wrote: > >>That's a really great idea!!! Almost sounds like a manifesto rather >>than hate!!! > > > Since when can't manifestos not be hate filled? > > Actually, You are right. They really couldn't be considered decent manifestos if they weren't hate filled. Excelent hate on all sides!
From: Juerd Date: 16:25 on 23 Apr 2005 Subject: Re: Upgrading without central packaging Peter da Silva skribis 2005-04-23 8:16 (-0500): > And on Mac OS, installing applications has always been easy. But the > people writing cross-platform applications have spent a lot of time and > effort coming up with packaging schemes and installers, and so have > transferred both of them over to Mac OS X. Yes, installing a program is easy. Upgrading it is too. Even removing it is easy. But none of it can easily be done in bulk, which means that if you want to do more than one program, the easy bit is gone. > Try http://macupdate.com/ instead. You can update the rest of the apps you use > at the same time. That helps. But it feels like one of those GUIs for Debian's apt, a big difference being that this GUI can only search and install, while apt GUIs can also upgrade and remove from a central application. > > 5. double click an icon (dmg) > Click on the name in the download window. Good idea. > > 6. drag another icon to the Applications folder > And you get to say WHERE you want it, it doesn't just vanish into the > dark forest of /usr. So when you want to sync up your Mac at work with > the software on your Mac at home you just > rsync --rsh=ssh home.example.com::/Local /Local The synching thing is nice - still, this functionality could be integrated into package management for OS X. I agree that the /usr woods are convoluted and basically just suck. Application directories work much better. I don't understand why when something's easy, people stop trying to make it even easier. Why can't I just in a simple window (no website, no ads, no having to pay) type the name of the thing I want, and have the computer do all the repetitive tasks? That's what a computer is good at, and I prefer wasting my time doing things I like. > > 7. confirm that I want to replace the old one > > 8. close the Finder window again > Click on the "eject" button next to the volume name. Handy. Thanks. > > 9. select two icons (dmg and mounted volume) > > 10. drag them to Trash > Drag the DMG to "/Local/Installed" so you have a clean copy, and when > you clicked eject you unmounted the DMG and closed the window. And maintain updates in two places? That's even more work. If I need it again, I'll apt-ge^H^H^H^H^H^Hmanually download it again... > > And after all that hard labour, all that's upgraded is just one program! > http://macupdate.com/ or http://versiontracker.com/ > I prefer macupdate, Versiontracker is a bit tarpit-ish. If there's some magic software upgrading program hiding in there, it is indeed very good at hiding. > The 8-step procedure is easier for newbies than "apt-get install firefox". Yes. But this way, they will forever stay newbies. There is no more advanced level (well, some shortcuts like the two you indicated) of understanding, so there isn't more efficiency to be gained. In that respect, it is like PHP: made for newbies in a way that prevents them from ever reaching a higher level and power users from doing things efficiently. Juerd
From: peter (Peter da Silva) Date: 23:03 on 23 Apr 2005 Subject: Re: Upgrading without central packaging > But none of it can easily be done in bulk, which means that if you want > to do more than one program, the easy bit is gone. That's true. If I needed to do it in bulk, because, say, my system was a GNOME style rats-nest of incompatble dependencies, I'd hate not being able to do it in bulk. Luckily it's not. > That helps. But it feels like one of those GUIs for Debian's apt, a big > difference being that this GUI can only search and install, while apt > GUIs can also upgrade and remove from a central application. Lets get together some time for a hate-fest for things that only come in GUI form, with a side-order of stuff that only comes with a web-interface that doesn't even work without a modern browser and lots of CSS and Javascript magic so you can't even script access to it easily. Oh yes, oh yes. > I don't understand why when something's easy, people stop trying to make > it even easier. Because good enough is good enough, and if it's hard to make things a bit better that's where things stay. When getting things better involves herding cats (like, say, getting all developers to agree on how to standardise automatic update) it's real hard to make things better. The only way to break out of this is to pay someone (in money or egoboo) to do it, or for someone who thinks they can get money or egoboo from doing a better job somewhere else to provide competition. > > > 9. select two icons (dmg and mounted volume) > > > 10. drag them to Trash > > Drag the DMG to "/Local/Installed" so you have a clean copy, and when > > you clicked eject you unmounted the DMG and closed the window. > > And maintain updates in two places? That's even more work. If I need it > again, I'll apt-ge^H^H^H^H^H^Hmanually download it again... You'll learn. After a while you get tired of discovering that the people who made the software you use aren't in business any more. It's easier to keep a snapshot of what you're using that you know works... on an ongoing basis... than to have the occasional chinese fire drill when you have to track down the retrocomputing site that happens to still have a partial mirror of the website. I wish I'd done that when I could still get NeXTstep software. > > The 8-step procedure is easier for newbies than "apt-get install firefox". > Yes. But this way, they will forever stay newbies. You can't be an expert in everything. People buy Macs because they don't want to be expert computer dudes. Some of them end up learning quite a bit anyway, because they find something like scripting that's useful and challenging. If if they ARE only scripting PHP or Applescript, they're ahead of someone who's an expert in software installs.
From: Abigail Date: 23:23 on 23 Apr 2005 Subject: Re: Upgrading without central packaging --dkEUBIird37B8yKS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 23, 2005 at 05:03:52PM -0500, Peter da Silva wrote: >=20 > Lets get together some time for a hate-fest for things that only > come in GUI form, with a side-order of stuff that only comes with > a web-interface that doesn't even work without a modern browser > and lots of CSS and Javascript magic so you can't even script access > to it easily. Oh yes, oh yes. Ah, yes. HP sells those big disk arrays, called XPs. (Made by Hitachi, but there's an HP logo on the outside). XPs need to be configured using a webinterface. (Both the XP and webinterface have their chapter of hate).=20 It's not that HP doesn't understand the usefulness of scripting. They also sell smaller disk arrays called VA's (or used to, haven't dealt with HP for 2 years and their equipment goes EOL amazingly fast). Which can be=20 configured with both a webinterface, and with a CLI.=20 Anyway, XPs can now be configured using a CLI. But what a CLI it is. You have to type your commands inside a webbrowser. IIRC, inside a=20 textarea with some Javascript processing. (But it could be a Java applet as well). I used to tell my students that we've now come full circle. 30 years ago,= =20 we used the CLI. But that wasn't flashy enough. So, we got a GUI. But that wasn't portable enough. So we got the web wowser. But that wasn't handy. So, we got the CLI. Inside a web browser. Hate, hate, hate. Abigail --dkEUBIird37B8yKS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCasrLBOh7Ggo6rasRAvpzAKC76Y4ciCIvJdeh8Vnd9fehFIsSewCgw+ZU 7D/9IZw/ZZztFgtsleEIjJU= =OyYz -----END PGP SIGNATURE----- --dkEUBIird37B8yKS--
From: Juerd Date: 23:48 on 23 Apr 2005 Subject: Re: Upgrading without central packaging Peter da Silva skribis 2005-04-23 17:03 (-0500): > > And maintain updates in two places? That's even more work. If I need it > > again, I'll apt-ge^H^H^H^H^H^Hmanually download it again... > You'll learn. After a while you get tired of discovering that the people who > made the software you use aren't in business any more. Oh crap. Yeah, I'm rather spoiled with Debian's huge repository, and didn't realise the scattered sort-of equivalent that many sites together are doesn't have the same availability guarantees. > People buy Macs because they don't want to be expert computer dudes. Really? I bought mine for two reasons: 1. The Mini is small and silent in a way that no PC for this price can be 2. Expert computer dudes keep recommending OS X. Now that I have used it for a month, I still don't really understand why. I'd recommend it over Windows any time, and it's as usable as KDE on average (only because the terminal focus hotkeys make up for a lot), so I can hopefully continue to use it without hating it too much, but there's no "I love my mac" from me. Well, I love the hardware. > If if they ARE only scripting PHP or Applescript, they're ahead of someone > who's an expert in software installs. ++ Juerd
From: Michael G Schwern Date: 01:04 on 24 Apr 2005 Subject: Re: Upgrading without central packaging On Sun, Apr 24, 2005 at 12:48:10AM +0200, Juerd wrote: > 2. Expert computer dudes keep recommending OS X. Now that I have used it > for a month, I still don't really understand why. I'd recommend it over > Windows any time, and it's as usable as KDE on average (only because the > terminal focus hotkeys make up for a lot) default write com.apple.Terminal FocusFollowsMouse -string YES http://www.macosxhints.com/article.php?story=20031029203936659 defaults write com.apple.x11 wm_ffm true http://www.macosxhints.com/comment.php?mode=display&sid=20031029203936659&title=X11+focus-follow+mouse+option&type=article&order=&pid=29952 The hate here is if you want FFM for all apps you have to buy something like CodeTek Virtual Desktop. > so I can hopefully continue > to use it without hating it too much, but there's no "I love my mac" > from me. Well, I love the hardware. The power of Unix and the relatively sensibly designed GUI of MacOS without the hate of having to recompile your kernel, fuck around in /etc or install drivers to get your wireless card working. Too bad its really fucking slow.
From: peter (Peter da Silva) Date: 02:17 on 24 Apr 2005 Subject: Re: Upgrading without central packaging > Oh crap. Yeah, I'm rather spoiled with Debian's huge repository, and > didn't realise the scattered sort-of equivalent that many sites together > are doesn't have the same availability guarantees. Indeed. Start saving now. You'll be amazed what you'll suddenly need in a few years. > > People buy Macs because they don't want to be expert computer dudes. > Really? In general, yes, that's Apple's core market. And expert computer dudes sometimes get tired of being expert computer dudes all the damn time. > 2. Expert computer dudes keep recommending OS X. Now that I have used it > for a month, I still don't really understand why. I can get enough commercial software for it I don't have any need to run Windows. It's the only UNIX that has Microsoft Office in any meaningful sense. If you can already manage to avoid Windows, then I can see why it's not nearly as exciting for you.
From: Robin Stephenson
Date: 15:01 on 26 Apr 2005
Subject: Subversion (was: Re: Upgrading without central packaging)
Peter da Silva wrote:
> [...]
>
>a GNOME
>style rats-nest of incompatble dependencies
>
A while back I built Subversion. There's software modularity and reuse,
and there's Dependency Madness:
root@ndovu:~# ldd `which svn`
libsvn_client-1.so.0 => /usr/local/lib/libsvn_client-1.so.0
libsvn_wc-1.so.0 => /usr/local/lib/libsvn_wc-1.so.0
libsvn_ra-1.so.0 => /usr/local/lib/libsvn_ra-1.so.0
libsvn_diff-1.so.0 => /usr/local/lib/libsvn_diff-1.so.0
libsvn_ra_local-1.so.0 => /usr/local/lib/libsvn_ra_local-1.so.0
libsvn_repos-1.so.0 => /usr/local/lib/libsvn_repos-1.so.0
libsvn_fs-1.so.0 => /usr/local/lib/libsvn_fs-1.so.0
libsvn_fs_fs-1.so.0 => /usr/local/lib/libsvn_fs_fs-1.so.0
libsvn_fs_base-1.so.0 => /usr/local/lib/libsvn_fs_base-1.so.0
libsvn_ra_svn-1.so.0 => /usr/local/lib/libsvn_ra_svn-1.so.0
libsvn_ra_dav-1.so.0 => /usr/local/lib/libsvn_ra_dav-1.so.0
libsvn_delta-1.so.0 => /usr/local/lib/libsvn_delta-1.so.0
libsvn_subr-1.so.0 => /usr/local/lib/libsvn_subr-1.so.0
libaprutil-0.so.0 => /usr/local/apr/lib/libaprutil-0.so.0
libgdbm.so.3 => /usr/local/lib/libgdbm.so.3
libdb-4.2.so => /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so
libexpat.so.0 => /usr/local/lib/libexpat.so.0
libapr-0.so.0 => /usr/local/apr/lib/libapr-0.so.0
libsendfile.so.1 => /usr/lib/libsendfile.so.1
librt.so.1 => /usr/lib/librt.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libdl.so.1 => /usr/lib/libdl.so.1
libneon.so.24 => /usr/local/lib/libneon.so.24
libxml2.so.2 => /usr/local/lib/libxml2.so.2
libpthread.so.1 => /usr/lib/libpthread.so.1
libiconv.so.2 => /usr/local/lib/libiconv.so.2
libz.so => /usr/local/lib/libz.so
libm.so.1 => /usr/lib/libm.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libc.so.1 => /usr/lib/libc.so.1
libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1
libaio.so.1 => /usr/lib/libaio.so.1
libz.so.1 (SUNW_1.1) => (version not found)
libz.so.1 (SUNW_1.1) => (version not found)
libmp.so.2 => /usr/lib/libmp.so.2
libthread.so.1 => /usr/lib/libthread.so.1
/usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1
I still don't understand why ldd is moaning about libz:
/usr/lib/libz.so.1 f none 0755 root bin 70064 21161 1065228442 SUNWzlib
Other Subversion gripes:
* Using more w3c standards than anyone else is not a claim to greatness
* Eclipse support is broken: it checks out, but can't check in
* The bastard thing wedges its repository every time someone looks at it
funny; there doesn't seem to be a way to tell it to automatically roll
back failed transactions (say after 30 minutes)
* When it does wedge it goes to some lengths to put the fear of God into
the user:
svn: Berkeley DB error while opening environment for filesystem /svn/db:
DB_RUNRECOVERY: Fatal error, run database recovery
svn: bdb: PANIC: fatal region error detected; run recovery
svn: Your commit message was left in a temporary file:
svn: '/etc/svn-commit.2.tmp'
* why oh why didn't they provide some way to store Unix permissions and
ownerships (VC of system files)? Don't tell me properties are it; I
don't want to write wrappers, CVS made me do that, it sucked then, and
it sucks now.
I only really have one problem with this: how the hell am I expected to
persuade a room full of Java developers that this is an improvement over
CVS? I mean, it is, but it's just blimmin well not a big enough one.
Finally, line endings. Oh, line endings. Eclipse's wild stabs in the
dark, FTP's binary vs ASCII transfer, Cygwin's weird mount thing,
getting everyone to delete their working copy to fix sticky tags in CVS,
rubbish Unix error messages ("bad interpreter?") -- I've just about had
it up to here.
Can anyone name a single piece of software that doesn't suck? There must
be some small, perfectly formed jewel out there that does something
useful, right? Right?
From: Darrell Fuhriman Date: 15:15 on 26 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) > Can anyone name a single piece of software that doesn't suck? There must > be some small, perfectly formed jewel out there that does something > useful, right? Right? halt(8) Darrell
From: peter (Peter da Silva) Date: 17:37 on 26 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) > > Can anyone name a single piece of software that doesn't suck? There must > > be some small, perfectly formed jewel out there that does something > > useful, right? Right? > halt(8) That's a symlink to reboot, now at revision 1.24 with several main forks and a revision log almost 7k long. And that ignores all the kernel pain that dealing with ACPI imposes.
From: John Sinteur Date: 17:41 on 26 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) On Apr 26, 2005, at 18:37, Peter da Silva wrote: >> halt(8) >> > > That's a symlink to reboot, now at revision 1.24 with several main > forks and > a revision log almost 7k long. And that ignores all the kernel pain > that > dealing with ACPI imposes. That's why I always use "yes | /dev/kmem" instead. -John
From: peter (Peter da Silva) Date: 04:31 on 27 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) > That's why I always use "yes | /dev/kmem" instead. dd if=/dev/kmem of=/dev/kmem bs=1 skip=1
From: David Champion Date: 18:52 on 27 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) * On 2005.04.26, in <20050427033118.C58E7413C6@xxxxxxx.xx.xxxxxxx.xxx>, * "Peter da Silva" <peter@xxxxxxx.xxx> wrote: > > That's why I always use "yes | /dev/kmem" instead. > > dd if=/dev/kmem of=/dev/kmem bs=1 skip=1 And on AIX, conv=ebcdic.
From: Darrell Fuhriman Date: 17:49 on 26 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) > That's a symlink to reboot, now at revision 1.24 with several main forks and > a revision log almost 7k long. And that ignores all the kernel pain that > dealing with ACPI imposes. That assumes I care if the computer can come back. Darrell
From: David Cantrell Date: 17:51 on 26 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) On Tue, Apr 26, 2005 at 11:37:18AM -0500, Peter da Silva wrote: > > > Can anyone name a single piece of software that doesn't suck? There must > > > be some small, perfectly formed jewel out there that does something > > > useful, right? Right? > > halt(8) > That's a symlink to reboot, now at revision 1.24 with several main forks and > a revision log almost 7k long. And that ignores all the kernel pain that > dealing with ACPI imposes. <hides under desk, sobbing>
From: peter (Peter da Silva) Date: 15:34 on 26 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) > Can anyone name a single piece of software that doesn't suck? There must > be some small, perfectly formed jewel out there that does something > useful, right? Right? If there is then RIGHT NOW someone is extending it so it can read mail.
From: Xtina Date: 17:01 on 26 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) On 4/26/05, Peter da Silva <peter@xxxxxxx.xxx> wrote: > If there is then RIGHT NOW someone is extending it so it can read mail. Found elsewhere: Next, I designed, and Terry Weissman and I implemented, the Netscape Mail and News clients, versions 2.0 through 3.0. This was our contribution to the proof of the Law of Software Envelopment: ``Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.'' http://www.jwz.org/hacks/
From: Simon Wistow
Date: 17:06 on 26 Apr 2005
Subject: Re: Subversion (was: Re: Upgrading without central packaging)
On Tue, Apr 26, 2005 at 12:01:48PM -0400, Xtina said:
> ``Every program attempts to expand until it can read mail. Those
> programs which cannot so expand are replaced by ones which can.''
Of course now the law is
``Every program evolves until it has themes. And uses XML. Somehow.
It doesn't really matter what for it just does. Maybe for the the
themes. Mmmmm - themes.''
From: peter (Peter da Silva) Date: 18:19 on 26 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) > ``Every program evolves until it has themes. And uses XML. Somehow. > It doesn't really matter what for it just does. Maybe for the the > themes. Mmmmm - themes.'' /boot/chrome/themeBoot.xml /boot/chrome/backdrop.jpg /boot/chrome/themeReboot.xml /boot/chrome/themeHalt.xml /boot/chrome/themePanic.xml /boot/chrome/glass.mp3 /boot/chrome/TheFreeBSDSound.mp3 /boot/chrome/FreeBSDShutdown.mp3 /boot/chrome/java_loader.4th /boot/chrome/ChuckWalking.jar /boot/chrome/ChuckFinger.jar
From: Earle Martin Date: 01:22 on 03 May 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) On Tue, Apr 26, 2005 at 12:01:48PM -0400, Xtina wrote: > ``Every program attempts to expand until it can read mail. Those > programs which cannot so expand are replaced by ones which can.'' Back on MacOS Classic, the rule seemed to be s/read mail/BinHex or unBinHex files/ . I have no idea why.
From: Chris Devers
Date: 18:41 on 26 Apr 2005
Subject: Re: Subversion (was: Re: Upgrading without central packaging)
On Tue, 26 Apr 2005, Robin Stephenson wrote:
> A while back I built Subversion. There's software modularity and reuse, and
> there's Dependency Madness:
Indeed.
$ grep Depends /sw/fink/10.3/unstable/main/finkinfo/devel/svn-0.33.1-11.info
Depends: %N-shlibs (= %v-%r), swig (>= 1.3.16-12)
BuildDepends: apr (>= 0.9.5-1), db41 (>= 4.1.25-15), gdbm3, expat (>= 1.95.6-2), libxml2 (>= 2.5.10-12), python | python-nox, fink (>= 0.16.0-1), neon24 (>= 0.24.4-11), swig (>= 1.3.16-12), texinfo (>= 4.2-22), libiconv-dev (>= 1.9.1-11), libtool14 (>= 1.5-1), apache2-dev (>= 2.0.48-2), system-java14-dev
Depends: %N-shlibs (= %v-%r)
BuildDependsOnly: True
Depends: apr-shlibs (>= 0.9.5-1), db41-shlibs (>= 4.1.25-15), gdbm3-shlibs, expat-shlibs (>= 1.95.3-1), libxml2-shlibs (>= 2.5.10-12), neon24-shlibs (>= 0.24.4-11), swig (>= 1.3.16-12), system-java14
Depends: %N-shlibs (= %v-%r)
BuildDependsOnly: True
Depends: %N-shlibs (= %v-%r), apache2 (>= 2.0.48-2)
$
Why on earth should a frickin' source code management system depend, not
just on a web server, not just on Apache, but on frickin' Apache 2?
Clearly these people hate the world.
Clearly they want to make a new one in their image.
That or, clearly, they just don't want people to use SVN.
Works for me.
From: Arthur Bergman Date: 18:45 on 26 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) On 26 Apr 2005, at 18:41, Chris Devers wrote: > On Tue, 26 Apr 2005, Robin Stephenson wrote: > >> A while back I built Subversion. There's software modularity and >> reuse, and >> there's Dependency Madness: > > Indeed. > > $ grep Depends > /sw/fink/10.3/unstable/main/finkinfo/devel/svn-0.33.1-11.info > Depends: %N-shlibs (= %v-%r), swig (>= 1.3.16-12) > BuildDepends: apr (>= 0.9.5-1), db41 (>= 4.1.25-15), gdbm3, expat > (>= 1.95.6-2), libxml2 (>= 2.5.10-12), python | python-nox, fink (>= > 0.16.0-1), neon24 (>= 0.24.4-11), swig (>= 1.3.16-12), texinfo (>= > 4.2-22), libiconv-dev (>= 1.9.1-11), libtool14 (>= 1.5-1), apache2-dev > (>= 2.0.48-2), system-java14-dev > Depends: %N-shlibs (= %v-%r) > BuildDependsOnly: True > Depends: apr-shlibs (>= 0.9.5-1), db41-shlibs (>= 4.1.25-15), > gdbm3-shlibs, expat-shlibs (>= 1.95.3-1), libxml2-shlibs (>= > 2.5.10-12), neon24-shlibs (>= 0.24.4-11), swig (>= 1.3.16-12), > system-java14 > Depends: %N-shlibs (= %v-%r) > BuildDependsOnly: True > Depends: %N-shlibs (= %v-%r), apache2 (>= 2.0.48-2) > $ > > Why on earth should a frickin' source code management system depend, > not > just on a web server, not just on Apache, but on frickin' Apache 2? > > Clearly these people hate the world. > > Clearly they want to make a new one in their image. > > That or, clearly, they just don't want people to use SVN. > > Works for me. > > Guys guys guys, subversion is the reason I came up with the idea of this list! Precursor hate is found at http://use.perl.org/~sky/journal/13809 and http://www.nntp.perl.org/group/perl.ponie.dev/15 Cheers Arthur ----- CTO @ Fotango Ltd +447834716919 http://www.fotango.com/ ----- CTO @ Fotango Ltd +447834716919 http://www.fotango.com/ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
From: Nicholas Clark Date: 18:51 on 26 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) I hate the way that the subversion client library code is so efficient that despite being written in C, it can be outperformed by an alternative implementation in Perl code. (svk). Meanwhile I'll hate svk for having shed loads of dependencies including SWIG, and thereby being a bitch to build from source. My other opinions of svk and svn are off topic for this list. Nicholas Clark
From: peter (Peter da Silva) Date: 00:39 on 27 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) > Meanwhile I'll hate svk for having shed loads of dependencies including SWIG, not to mention all the dependencies that being written in Perl usually carries with it, or did they avoid taking a big drag on the CPAN pipe?
From: Michael G Schwern Date: 01:04 on 27 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) On Tue, Apr 26, 2005 at 06:39:02PM -0500, Peter da Silva wrote: > > Meanwhile I'll hate svk for having shed loads of dependencies including SWIG, > > not to mention all the dependencies that being written in Perl usually carries > with it, or did they avoid taking a big drag on the CPAN pipe? SVK is the dependencyist! 20 dependent modules. http://search.cpan.org/src/CLKAO/SVK-0.993/META.yml CPAN-o-phobes can find prebuilt bundles for OS X and Windows with all dependencies (including SVN) herein http://rt.openfoundry.org/Foundry/Project/Download/?Queue=82
From: Chris Devers Date: 01:12 on 27 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) On Tue, 26 Apr 2005, Michael G Schwern wrote: > SVK is the dependencyist! 20 dependent modules. > http://search.cpan.org/src/CLKAO/SVK-0.993/META.yml I'll see your SVK and raise you an RT! In RT 3.4.1, I count 30 "core" modules -- many of which, charmingly, have to be the very latest versions, so no your Debian package ain't gonna cut it -- plus another dozen for Mason, four for the mailgate, and oh say another dozen or so depending on how you configure it. It looks like a typical setup would easily get to around 50 dependencies. If something you wrote can top this ... rewrite it. For the love of god.
From: Michael G Schwern Date: 01:39 on 27 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) On Tue, Apr 26, 2005 at 08:12:42PM -0400, Chris Devers wrote: > In RT 3.4.1, I count 30 "core" modules -- many of which, charmingly, > have to be the very latest versions, so no your Debian package ain't > gonna cut it ...except there is a Debian package for RT. :) > -- plus another dozen for Mason, four for the mailgate, and > oh say another dozen or so depending on how you configure it. It looks > like a typical setup would easily get to around 50 dependencies. > > If something you wrote can top this ... rewrite it. For the love of god. Devel::ebug. 27 dependencies. But wait... one of them is Catalyst. 17 dependencies. The associated scatter might push it over RT. Of course, this dependency hate is largely unfair. Leon Brocard pretty much developed a whole new graphical perl debugger light years better than the existing one in less than a month. RT beats the ever lovin crap out of Bugzilla and its largely the work of one man: Jesse Vincent. With SVK, clkao put together a quite nice, stable, fast distributed version control system in about a year and a half. Part of the reason they could accomplish this was not having to worry about anything but the new application code and just pulling pre-built stuff from CPAN. Dependency bloat is hateful but necessary for rapid development. If you really hate it roll a PAR bundle or improve CPAN because or do something to make dependencies easier to install and manage because there's no backing away from modules now.
From: Robert G. Werner Date: 02:10 on 27 Apr 2005 Subject: Re: Subversion Michael G Schwern wrote: [snip] > Part of the reason they could accomplish this was not having to worry about > anything but the new application code and just pulling pre-built stuff from > CPAN. Dependency bloat is hateful but necessary for rapid development. > If you really hate it roll a PAR bundle or improve CPAN because or do something > to make dependencies easier to install and manage because there's no backing > away from modules now. > > I totally agree. The dependancies are a pain when you are deploying to servers you don't control. But when you can use CPAN|CPANPLUS or even just perl Makefile.PL;make;make test;make install it's not so bad. I really like using well tested code to do things I don't want to have to think about figuring out. Probably my favorite Module right now is Net::SMTP, especially since it is in core. Makes deploying a web app on Win* less hateful. Also nice when local sendmail|postfix|exim|whatever hasn't been configured.
From: Juerd
Date: 09:59 on 27 Apr 2005
Subject: Re: Subversion
Robert G. Werner skribis 2005-04-26 18:10 (-0700):
> I totally agree. The dependancies are a pain when you are deploying
> to servers you don't control. But when you can use CPAN|CPANPLUS or
> even just perl Makefile.PL;make;make test;make install it's not so
> bad. I really like using well tested code to do things I don't want
> to have to think about figuring out. Probably my favorite Module
> right now is Net::SMTP, especially since it is in core. Makes
> deploying a web app on Win* less hateful. Also nice when local
> sendmail|postfix|exim|whatever hasn't been configured.
If there is a directory you are allowed to put files in, there's a way
to use CPAN.pm.
perldoc -q 'my own'
It should be much easier, though!
Juerd
From: Jarkko Hietaniemi Date: 17:10 on 27 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) Chris Devers wrote: > On Tue, 26 Apr 2005, Michael G Schwern wrote: > > >>SVK is the dependencyist! 20 dependent modules. >>http://search.cpan.org/src/CLKAO/SVK-0.993/META.yml > > > I'll see your SVK and raise you an RT! > > In RT 3.4.1, I count 30 "core" modules -- many of which, charmingly, > have to be the very latest versions, so no your Debian package ain't > gonna cut it -- plus another dozen for Mason, four for the mailgate, and > oh say another dozen or so depending on how you configure it. It looks > like a typical setup would easily get to around 50 dependencies. > > If something you wrote can top this ... rewrite it. For the love of god. How is Slashcode doing these days, dependencywise? > >
From: Yoz Grahame Date: 17:38 on 27 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) On 4/27/05, Jarkko Hietaniemi <jhi@xxx.xx> wrote: >=20 > How is Slashcode doing these days, dependencywise? http://search.cpan.org/~cnandor/Bundle-Slash-2.51/Slash.pm hahahahahaaaaaaohgod. If they ever come up with a way to add hardware delivery to CPAN Bundles, this is a prime candidate for a few extra DIMMs. -- Yoz
From: Simon Wistow Date: 18:10 on 27 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) > hahahahahaaaaaaohgod. If they ever come up with a way to add hardware > delivery to CPAN Bundles, this is a prime candidate for a few extra > DIMMs. Hell, it should just go all PHP on its ass and bundle everything either as core or statically. Or reinvent its own wheels and bundle *those* statically. Oh, wait. That was sarcasm. Simon [ who is currently dealing with both dynamic and static library hell and hating both equally ]
From: Jarkko Hietaniemi Date: 05:46 on 27 Apr 2005 Subject: Re: Subversion > > My other opinions of svk and svn are off topic for this list. Certainly you can't... *gulp* love *shudder* some software? > Nicholas Clark
From: Darrell Fuhriman Date: 18:46 on 26 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) > Why on earth should a frickin' source code management system depend, not > just on a web server, not just on Apache, but on frickin' Apache 2? mod_dav/mod_svn But SVN doesn't actually require that (although it's recommended). The packagers made that dependency. We don't have a webserver with our svn repository. Darrell
From: Michael G Schwern Date: 21:14 on 26 Apr 2005 Subject: Re: Subversion (was: Re: Upgrading without central packaging) --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 26, 2005 at 03:01:23PM +0100, Robin Stephenson wrote: > * When it does wedge it goes to some lengths to put the fear of God into > the user: > > svn: Berkeley DB error while opening environment for filesystem /svn/db: > DB_RUNRECOVERY: Fatal error, run database recovery > svn: bdb: PANIC: fatal region error detected; run recovery > svn: Your commit message was left in a temporary file: > svn: '/etc/svn-commit.2.tmp' For god's sake man, switch to FSFS! http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-5-sect-1.3 Hating subversion for still not making fsfs the default repo type and requiring folks to use the devel branch to get at a sensible repo. > I only really have one problem with this: how the hell am I expected to > persuade a room full of Java developers that this is an improvement over > CVS? I mean, it is, but it's just blimmin well not a big enough one. svn mv. Oh god, svn mv alone is enough reason. Also per change revision numbers, thank you! > Finally, line endings. Oh, line endings. Eclipse's wild stabs in the > dark, FTP's binary vs ASCII transfer, Cygwin's weird mount thing, > getting everyone to delete their working copy to fix sticky tags in CVS, > rubbish Unix error messages ("bad interpreter?") -- I've just about had > it up to here. svn:eol-style and svn:mime-type? http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-7-sect-2.3.5 Or does that just add to the hate? > Can anyone name a single piece of software that doesn't suck? There must > be some small, perfectly formed jewel out there that does something > useful, right? Right? I've been liking darcs lately, no server to set up! You go into your working directory... darcs init; darcs add -r .; darcs record; and go. Want to make the repo available? Point a dumb ol web server at your working copy. Not that it doesn't have its own hate. The Worst Annotation Format In The Universe can be seen attached along with the file its annotating. --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Description: add.pl-annotated Content-Disposition: attachment; filename="add.pl-annotated" # File tests/add.pl created by [a test for adding directories # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20041022172931 I added a (failing) test for adding a new directory. The bug is simply in the diagnostic message returned. The directory is referred to a file when it should be referred to as a directory to be less confusing. Here's what the failing test output looks like now: not ok 1 - Make sure that messages about directories call them directories. # Failed test (add.pl at line 20) # 'A file named foo.d is already in the repository! # Note that to ensure portability we don't allow files that differ # only in case. # ' # doesn't match '(?-xism:directory)' ] as ./tests/add.pl # Following line added by [a test for adding directories # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20041022172931 I added a (failing) test for adding a new directory. The bug is simply in the diagnostic message returned. The directory is referred to a file when it should be referred to as a directory to be less confusing. Here's what the failing test output looks like now: not ok 1 - Make sure that messages about directories call them directories. # Failed test (add.pl at line 20) # 'A file named foo.d is already in the repository! # Note that to ensure portability we don't allow files that differ # only in case. # ' # doesn't match '(?-xism:directory)' ] #!/usr/bin/env perl # Following line added by [a test for adding directories # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20041022172931 I added a (failing) test for adding a new directory. The bug is simply in the diagnostic message returned. The directory is referred to a file when it should be referred to as a directory to be less confusing. Here's what the failing test output looks like now: not ok 1 - Make sure that messages about directories call them directories. # Failed test (add.pl at line 20) # 'A file named foo.d is already in the repository! # Note that to ensure portability we don't allow files that differ # only in case. # ' # doesn't match '(?-xism:directory)' ] # Following line added by [a test for adding directories # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20041022172931 I added a (failing) test for adding a new directory. The bug is simply in the diagnostic message returned. The directory is referred to a file when it should be referred to as a directory to be less confusing. Here's what the failing test output looks like now: not ok 1 - Make sure that messages about directories call them directories. # Failed test (add.pl at line 20) # 'A file named foo.d is already in the repository! # Note that to ensure portability we don't allow files that differ # only in case. # ' # doesn't match '(?-xism:directory)' ] # Some tests for 'darcs add' # Following line added by [a test for adding directories # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20041022172931 I added a (failing) test for adding a new directory. The bug is simply in the diagnostic message returned. The directory is referred to a file when it should be referred to as a directory to be less confusing. Here's what the failing test output looks like now: not ok 1 - Make sure that messages about directories call them directories. # Failed test (add.pl at line 20) # 'A file named foo.d is already in the repository! # Note that to ensure portability we don't allow files that differ # only in case. # ' # doesn't match '(?-xism:directory)' ] # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] use lib qw(lib/perl); # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] # Following line added by [Test::Darcs. darcs() instead of `$DARCS ...` # schwern@xxxxx.xxx**20050312031120 All the perl tests repeat this mantra to find darcs: use vars qw/$DARCS/; die 'darcs not found' unless $ENV{DARCS} || (-x "$ENV{PWD}/../darcs"); $DARCS = $ENV{DARCS} || "$ENV{PWD}/../darcs"; And then they call $DARCS directly via a shell command. `$DARCS ...` Repeated code is bad and all that shell is likely to become a compatibility liability. This patch creats a library Test::Darcs and in it darcs() which replaces `$DARCS ...`. I've converted add.pl to use it as a demonstration. One of the issues is now in order to run an individual Perl test file you must add -Ilib/perl so it can find Test::Darcs. Alternatively one can add "use lib qw(lib/perl)" to all the Perl tests. I don't know which is better for darcs developers. The latter is redundant but potentially less confusing. More testing libraries for tests/lib/perl to follow. ] use Test::More qw/no_plan/; # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] # Following line added by [Test::Darcs. darcs() instead of `$DARCS ...` # schwern@xxxxx.xxx**20050312031120 All the perl tests repeat this mantra to find darcs: use vars qw/$DARCS/; die 'darcs not found' unless $ENV{DARCS} || (-x "$ENV{PWD}/../darcs"); $DARCS = $ENV{DARCS} || "$ENV{PWD}/../darcs"; And then they call $DARCS directly via a shell command. `$DARCS ...` Repeated code is bad and all that shell is likely to become a compatibility liability. This patch creats a library Test::Darcs and in it darcs() which replaces `$DARCS ...`. I've converted add.pl to use it as a demonstration. One of the issues is now in order to run an individual Perl test file you must add -Ilib/perl so it can find Test::Darcs. Alternatively one can add "use lib qw(lib/perl)" to all the Perl tests. I don't know which is better for darcs developers. The latter is redundant but potentially less confusing. More testing libraries for tests/lib/perl to follow. ] use Test::Darcs; # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] use Shell::Command; # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] # Following line added by [a test for adding directories # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20041022172931 I added a (failing) test for adding a new directory. The bug is simply in the diagnostic message returned. The directory is referred to a file when it should be referred to as a directory to be less confusing. Here's what the failing test output looks like now: not ok 1 - Make sure that messages about directories call them directories. # Failed test (add.pl at line 20) # 'A file named foo.d is already in the repository! # Note that to ensure portability we don't allow files that differ # only in case. # ' # doesn't match '(?-xism:directory)' ] use strict; # Following line added by [a test for adding directories # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20041022172931 I added a (failing) test for adding a new directory. The bug is simply in the diagnostic message returned. The directory is referred to a file when it should be referred to as a directory to be less confusing. Here's what the failing test output looks like now: not ok 1 - Make sure that messages about directories call them directories. # Failed test (add.pl at line 20) # 'A file named foo.d is already in the repository! # Note that to ensure portability we don't allow files that differ # only in case. # ' # doesn't match '(?-xism:directory)' ] # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] rm_rf 'temp1'; # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] mkpath 'temp1'; # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] chdir 'temp1'; # Following line added by [Allow parens to be optional when calling darcs() test command in some cases. # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20050312142220] darcs 'init'; # Following line added by [a test for adding directories # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20041022172931 I added a (failing) test for adding a new directory. The bug is simply in the diagnostic message returned. The directory is referred to a file when it should be referred to as a directory to be less confusing. Here's what the failing test output looks like now: not ok 1 - Make sure that messages about directories call them directories. # Failed test (add.pl at line 20) # 'A file named foo.d is already in the repository! # Note that to ensure portability we don't allow files that differ # only in case. # ' # doesn't match '(?-xism:directory)' ] # Following line added by [a test for adding directories # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20041022172931 I added a (failing) test for adding a new directory. The bug is simply in the diagnostic message returned. The directory is referred to a file when it should be referred to as a directory to be less confusing. Here's what the failing test output looks like now: not ok 1 - Make sure that messages about directories call them directories. # Failed test (add.pl at line 20) # 'A file named foo.d is already in the repository! # Note that to ensure portability we don't allow files that differ # only in case. # ' # doesn't match '(?-xism:directory)' ] ### # Following line added by [a test for adding directories # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20041022172931 I added a (failing) test for adding a new directory. The bug is simply in the diagnostic message returned. The directory is referred to a file when it should be referred to as a directory to be less confusing. Here's what the failing test output looks like now: not ok 1 - Make sure that messages about directories call them directories. # Failed test (add.pl at line 20) # 'A file named foo.d is already in the repository! # Note that to ensure portability we don't allow files that differ # only in case. # ' # doesn't match '(?-xism:directory)' ] # Following line added by [a test for adding directories # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20041022172931 I added a (failing) test for adding a new directory. The bug is simply in the diagnostic message returned. The directory is referred to a file when it should be referred to as a directory to be less confusing. Here's what the failing test output looks like now: not ok 1 - Make sure that messages about directories call them directories. # Failed test (add.pl at line 20) # 'A file named foo.d is already in the repository! # Note that to ensure portability we don't allow files that differ # only in case. # ' # doesn't match '(?-xism:directory)' ] my $test_name = 'Make sure that messages about directories call them directories.'; # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] mkpath 'foo.d'; # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] mkpath 'oof.d'; # Following line added by [Allow parens to be optional when calling darcs() test command in some cases. # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20050312142220] darcs qw( add foo.d ); # Following line added by [Allow parens to be optional when calling darcs() test command in some cases. # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20050312142220] darcs qw( add oof.d ); # Following line added by [fix conflict in add.pl. # David Roundy <droundy@xxxxxxxxxxx.xxx>**20041110114416] # Try adding the same directory when it's already in the repo # Following line added by [Test::Darcs. darcs() instead of `$DARCS ...` # schwern@xxxxx.xxx**20050312031120 All the perl tests repeat this mantra to find darcs: use vars qw/$DARCS/; die 'darcs not found' unless $ENV{DARCS} || (-x "$ENV{PWD}/../darcs"); $DARCS = $ENV{DARCS} || "$ENV{PWD}/../darcs"; And then they call $DARCS directly via a shell command. `$DARCS ...` Repeated code is bad and all that shell is likely to become a compatibility liability. This patch creats a library Test::Darcs and in it darcs() which replaces `$DARCS ...`. I've converted add.pl to use it as a demonstration. One of the issues is now in order to run an individual Perl test file you must add -Ilib/perl so it can find Test::Darcs. Alternatively one can add "use lib qw(lib/perl)" to all the Perl tests. I don't know which is better for darcs developers. The latter is redundant but potentially less confusing. More testing libraries for tests/lib/perl to follow. ] like(darcs(qw( add foo.d )), qr/directory/,$test_name); # Following line added by [Test::Darcs. darcs() instead of `$DARCS ...` # schwern@xxxxx.xxx**20050312031120 All the perl tests repeat this mantra to find darcs: use vars qw/$DARCS/; die 'darcs not found' unless $ENV{DARCS} || (-x "$ENV{PWD}/../darcs"); $DARCS = $ENV{DARCS} || "$ENV{PWD}/../darcs"; And then they call $DARCS directly via a shell command. `$DARCS ...` Repeated code is bad and all that shell is likely to become a compatibility liability. This patch creats a library Test::Darcs and in it darcs() which replaces `$DARCS ...`. I've converted add.pl to use it as a demonstration. One of the issues is now in order to run an individual Perl test file you must add -Ilib/perl so it can find Test::Darcs. Alternatively one can add "use lib qw(lib/perl)" to all the Perl tests. I don't know which is better for darcs developers. The latter is redundant but potentially less confusing. More testing libraries for tests/lib/perl to follow. ] like(darcs(qw( add foo.d oof.d )), qr/directories/,$test_name); # Following line added by [a test for adding directories # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20041022172931 I added a (failing) test for adding a new directory. The bug is simply in the diagnostic message returned. The directory is referred to a file when it should be referred to as a directory to be less confusing. Here's what the failing test output looks like now: not ok 1 - Make sure that messages about directories call them directories. # Failed test (add.pl at line 20) # 'A file named foo.d is already in the repository! # Note that to ensure portability we don't allow files that differ # only in case. # ' # doesn't match '(?-xism:directory)' ] # Following line added by [a test for adding directories # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20041022172931 I added a (failing) test for adding a new directory. The bug is simply in the diagnostic message returned. The directory is referred to a file when it should be referred to as a directory to be less confusing. Here's what the failing test output looks like now: not ok 1 - Make sure that messages about directories call them directories. # Failed test (add.pl at line 20) # 'A file named foo.d is already in the repository! # Note that to ensure portability we don't allow files that differ # only in case. # ' # doesn't match '(?-xism:directory)' ] ### # Following line added by [a test for adding directories # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20041022172931 I added a (failing) test for adding a new directory. The bug is simply in the diagnostic message returned. The directory is referred to a file when it should be referred to as a directory to be less confusing. Here's what the failing test output looks like now: not ok 1 - Make sure that messages about directories call them directories. # Failed test (add.pl at line 20) # 'A file named foo.d is already in the repository! # Note that to ensure portability we don't allow files that differ # only in case. # ' # doesn't match '(?-xism:directory)' ] # Following line added by [fix conflict in add.pl. # David Roundy <droundy@xxxxxxxxxxx.xxx>**20041110114416] $test_name = 'Make sure that messages about files call them files.'; # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] touch 'bar'; # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] touch 'baz'; # Following line added by [Allow parens to be optional when calling darcs() test command in some cases. # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20050312142220] darcs qw( add bar ) ; # Following line added by [Allow parens to be optional when calling darcs() test command in some cases. # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20050312142220] darcs qw( add baz ) ; # Following line added by [Test::Darcs. darcs() instead of `$DARCS ...` # schwern@xxxxx.xxx**20050312031120 All the perl tests repeat this mantra to find darcs: use vars qw/$DARCS/; die 'darcs not found' unless $ENV{DARCS} || (-x "$ENV{PWD}/../darcs"); $DARCS = $ENV{DARCS} || "$ENV{PWD}/../darcs"; And then they call $DARCS directly via a shell command. `$DARCS ...` Repeated code is bad and all that shell is likely to become a compatibility liability. This patch creats a library Test::Darcs and in it darcs() which replaces `$DARCS ...`. I've converted add.pl to use it as a demonstration. One of the issues is now in order to run an individual Perl test file you must add -Ilib/perl so it can find Test::Darcs. Alternatively one can add "use lib qw(lib/perl)" to all the Perl tests. I don't know which is better for darcs developers. The latter is redundant but potentially less confusing. More testing libraries for tests/lib/perl to follow. ] like(darcs(qw( add bar )), qr/following file is/, $test_name); # Following line added by [Test::Darcs. darcs() instead of `$DARCS ...` # schwern@xxxxx.xxx**20050312031120 All the perl tests repeat this mantra to find darcs: use vars qw/$DARCS/; die 'darcs not found' unless $ENV{DARCS} || (-x "$ENV{PWD}/../darcs"); $DARCS = $ENV{DARCS} || "$ENV{PWD}/../darcs"; And then they call $DARCS directly via a shell command. `$DARCS ...` Repeated code is bad and all that shell is likely to become a compatibility liability. This patch creats a library Test::Darcs and in it darcs() which replaces `$DARCS ...`. I've converted add.pl to use it as a demonstration. One of the issues is now in order to run an individual Perl test file you must add -Ilib/perl so it can find Test::Darcs. Alternatively one can add "use lib qw(lib/perl)" to all the Perl tests. I don't know which is better for darcs developers. The latter is redundant but potentially less confusing. More testing libraries for tests/lib/perl to follow. ] like(darcs(qw( add bar baz )), qr/following files are/, $test_name); # Following line added by [fix conflict in add.pl. # David Roundy <droundy@xxxxxxxxxxx.xxx>**20041110114416] # Following line added by [fix conflict in add.pl. # David Roundy <droundy@xxxxxxxxxxx.xxx>**20041110114416] ### # Following line added by [fix conflict in add.pl. # David Roundy <droundy@xxxxxxxxxxx.xxx>**20041110114416] # Following line added by [fix conflict in add.pl. # David Roundy <droundy@xxxxxxxxxxx.xxx>**20041110114416] $test_name = 'Make sure that messages about both files and directories say so.'; # Following line added by [Test::Darcs. darcs() instead of `$DARCS ...` # schwern@xxxxx.xxx**20050312031120 All the perl tests repeat this mantra to find darcs: use vars qw/$DARCS/; die 'darcs not found' unless $ENV{DARCS} || (-x "$ENV{PWD}/../darcs"); $DARCS = $ENV{DARCS} || "$ENV{PWD}/../darcs"; And then they call $DARCS directly via a shell command. `$DARCS ...` Repeated code is bad and all that shell is likely to become a compatibility liability. This patch creats a library Test::Darcs and in it darcs() which replaces `$DARCS ...`. I've converted add.pl to use it as a demonstration. One of the issues is now in order to run an individual Perl test file you must add -Ilib/perl so it can find Test::Darcs. Alternatively one can add "use lib qw(lib/perl)" to all the Perl tests. I don't know which is better for darcs developers. The latter is redundant but potentially less confusing. More testing libraries for tests/lib/perl to follow. ] like(darcs(qw( add bar foo.d )), qr/files and directories/, $test_name); # Following line added by [fix conflict in add.pl. # David Roundy <droundy@xxxxxxxxxxx.xxx>**20041110114416] # Following line added by [fix conflict in add.pl. # David Roundy <droundy@xxxxxxxxxxx.xxx>**20041110114416] ### # Following line added by [fix conflict in add.pl. # David Roundy <droundy@xxxxxxxxxxx.xxx>**20041110114416] # Following line added by [automatically add parent directories for darcs add # Benedikt Schmidt <beschmi@xxxxxxx.xx>**20050205014603 Instead of complaining that the parent directory of the file isn't in the repo, add parent directories recursively. (See Bug #20) ] $test_name = 'Make sure that parent directories are added for files.'; # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] mkpath 'a.d/aa.d/aaa.d'; # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] mkpath 'b.d/bb.d'; # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] touch 'a.d/aa.d/aaa.d/baz'; # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] touch 'a.d/aa.d/aaa.d/bar'; # Following line added by [Test::Darcs. darcs() instead of `$DARCS ...` # schwern@xxxxx.xxx**20050312031120 All the perl tests repeat this mantra to find darcs: use vars qw/$DARCS/; die 'darcs not found' unless $ENV{DARCS} || (-x "$ENV{PWD}/../darcs"); $DARCS = $ENV{DARCS} || "$ENV{PWD}/../darcs"; And then they call $DARCS directly via a shell command. `$DARCS ...` Repeated code is bad and all that shell is likely to become a compatibility liability. This patch creats a library Test::Darcs and in it darcs() which replaces `$DARCS ...`. I've converted add.pl to use it as a demonstration. One of the issues is now in order to run an individual Perl test file you must add -Ilib/perl so it can find Test::Darcs. Alternatively one can add "use lib qw(lib/perl)" to all the Perl tests. I don't know which is better for darcs developers. The latter is redundant but potentially less confusing. More testing libraries for tests/lib/perl to follow. ] like(darcs(qw( add a.d/aa.d/aaa.d/bar a.d/aa.d/aaa.d/baz b.d/bb.d )), qr/^$/, $test_name); # Following line added by [automatically add parent directories for darcs add # Benedikt Schmidt <beschmi@xxxxxxx.xx>**20050205014603 Instead of complaining that the parent directory of the file isn't in the repo, add parent directories recursively. (See Bug #20) ] ### # Following line added by [automatically add parent directories for darcs add # Benedikt Schmidt <beschmi@xxxxxxx.xx>**20050205014603 Instead of complaining that the parent directory of the file isn't in the repo, add parent directories recursively. (See Bug #20) ] # Following line added by [improvements for darcs add and adding parent directories # Benedikt Schmidt <beschmi@xxxxxxx.xx>**20050206000516 Don't check for parents of recursively added files and order files given on commandline. Add test for new behaviour. ] $test_name = 'Make sure that darcs doesn\'t complains about duplicate adds when adding parent dirs.'; # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] mkpath 'c.d/'; # Following line added by [Shell::Command to replace shell calls in perl tests # schwern@xxxxx.xxx**20050312033530 The perl tests make shell calls for trivial things which can be done just fine in Perl like touch, mkdir, rm -rf. These are compatibility problems waiting to happen. There is an existing module which provides Perl functions similar to common shell commands, Shell::Command. It is a wrapper around the core module ExtUtils::Command. I've provided a copy here so darcs users do not have to download and install it to run the tests. This patch converts add.pl to use Shell::Command eliminating all `` calls in that test as a demonstration. ] touch 'c.d/baz'; # Following line added by [Test::Darcs. darcs() instead of `$DARCS ...` # schwern@xxxxx.xxx**20050312031120 All the perl tests repeat this mantra to find darcs: use vars qw/$DARCS/; die 'darcs not found' unless $ENV{DARCS} || (-x "$ENV{PWD}/../darcs"); $DARCS = $ENV{DARCS} || "$ENV{PWD}/../darcs"; And then they call $DARCS directly via a shell command. `$DARCS ...` Repeated code is bad and all that shell is likely to become a compatibility liability. This patch creats a library Test::Darcs and in it darcs() which replaces `$DARCS ...`. I've converted add.pl to use it as a demonstration. One of the issues is now in order to run an individual Perl test file you must add -Ilib/perl so it can find Test::Darcs. Alternatively one can add "use lib qw(lib/perl)" to all the Perl tests. I don't know which is better for darcs developers. The latter is redundant but potentially less confusing. More testing libraries for tests/lib/perl to follow. ] like(darcs(qw( add c.d/baz c.d )), qr/^$/, $test_name); # Following line added by [improvements for darcs add and adding parent directories # Benedikt Schmidt <beschmi@xxxxxxx.xx>**20050206000516 Don't check for parents of recursively added files and order files given on commandline. Add test for new behaviour. ] ### # Following line added by [improvements for darcs add and adding parent directories # Benedikt Schmidt <beschmi@xxxxxxx.xx>**20050206000516 Don't check for parents of recursively added files and order files given on commandline. Add test for new behaviour. ] # Following line added by [Fix RT#266. Introduce is_symlink instead of isnt_symlink. # Tomasz Zielonka <tomasz.zielonka@xxxxx.xxx>**20050317121210] { # Following line added by [a TODO test which confirms that RT#266 is a regression # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20050312220846 I suspect of the recent symlink patches introduced this. Search 'darcs changes' for 'sym' to find it. ] my $test_name = 'adding a non-existent dir and file gives the expected message'; # Following line added by [a TODO test which confirms that RT#266 is a regression # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20050312220846 I suspect of the recent symlink patches introduced this. Search 'darcs changes' for 'sym' to find it. ] my $out = darcs(qw!add notadir/notafile!); # Following line added by [a TODO test which confirms that RT#266 is a regression # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20050312220846 I suspect of the recent symlink patches introduced this. Search 'darcs changes' for 'sym' to find it. ] like($out,qr/does not exist/i,$test_name); # Following line added by [a TODO test which confirms that RT#266 is a regression # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20050312220846 I suspect of the recent symlink patches introduced this. Search 'darcs changes' for 'sym' to find it. ] } # Following line added by [a TODO test which confirms that RT#266 is a regression # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20050312220846 I suspect of the recent symlink patches introduced this. Search 'darcs changes' for 'sym' to find it. ] # Following line added by [a test for adding directories # Mark Stosberg <mark@xxxxxxxxxxx.xxx>**20041022172931 I added a (failing) test for adding a new directory. The bug is simply in the diagnostic message returned. The directory is referred to a file when it should be referred to as a directory to be less confusing. Here's what the failing test output looks like now: not ok 1 - Make sure that messages about directories call them directories. # Failed test (add.pl at line 20) # 'A file named foo.d is already in the repository! # Note that to ensure portability we don't allow files that differ # only in case. # ' # doesn't match '(?-xism:directory)' ] # Following line added by [Condense "file already in repo" output when adding. Add related tests.