Recent Features
| |||||||||||||
Bitten by the Red Hat Perl bug (InfoWorld)Bitten by the Red Hat Perl bug (InfoWorld)Posted Aug 29, 2008 1:00 UTC (Fri) by Sutoka (guest, #43890)In reply to: Bitten by the Red Hat Perl bug (InfoWorld) by MattPerry Parent article: Bitten by the Red Hat Perl bug (InfoWorld)
>Don't put the patches into the distro if they aren't in the upstream.
So the distro will have to wait for a new release of the package before they could include it?
>As for Firefox, Mozilla should be encouraged to create their own
How is an extra step *easier*? I can't think of any distro thats not extremely niche that doesn't include Firefox in their default repositories. Mozilla also has a tendency to not support older versions of Firefox that some distros ship.
I can't possibly understand how having people that don't know much about your distro make packages for it, force you to manually add their repository to your lists, and then manually fetch it (post install) would be better than the people that know what they're doing making the package.
IMO, saying upstream should provide all packages (hell, for the application I write I don't even provide RPMs for the distro I run!) or banning distros from patching is simply a knee-jerk reaction to a quite rare occurrence.
(Log in to post comments)
Bitten by the Red Hat Perl bug (InfoWorld) Posted Aug 29, 2008 14:55 UTC (Fri) by MattPerry (guest, #46341) [Link]
> So the distro will have to wait for a new release of the package before
> they could include it?
Exactly. Ideally, distros shouldn't be shipping the software at all. If the vendor packages it, and you have the vendor's repository in your software update list, then you can update that package (or not) independent of the distro's time line.
> How is an extra step *easier*? I can't think of any distro thats not
In the following, let us assume that Firefox could be any application.
What is easier is that one can upgrade their operating system or the application independent of each other without having to learn the details of system administration. Right now, if I want a new version of Firefox, I have to upgrade my entire operating system which I do not want to do. This will also upgrade all of the other packages on my system. That's a big change just to get a new version of one program.
I could install Firefox from source, or install the binary from Mozilla, but then I am venturing into system administration territory. I have to open a shell and type commands, figure out where to put the files, adjust paths, etc.
Contrast this with Windows users who have the ease of just double-clicking the icon to start the installer. Windows users can upgrade software without having to upgrade everything else on their computer. Likewise, they can upgrade their OS and then reinstall older versions of application software with the same ease as installing the new.
Modern linux distros assume that everyone wants to run the latest versions of software on their systems. For people such as myself who may want to run a mix of software versions there is no easy way to do so. No current Linux distros cater to my desktop needs.
Bitten by the Red Hat Perl bug (InfoWorld) Posted Aug 29, 2008 15:28 UTC (Fri) by Sutoka (guest, #43890) [Link]
>Exactly. Ideally, distros shouldn't be shipping the software at
>all.
So we'd be abolishing Linux distros and relying on upstream to package their software against the magical combination of libraries on your system? Yeah, good luck with that happening.
>If the vendor packages it, and you have the vendor's
You'd need all the repositories for all of the dependencies. You'd also need the same repositories as upstream used, otherwise ABI incompatibilies might prevent it from working at all. You'd also have no way to be sure that your packages won't collide with each other, as theres no central authority making the packages to prevent that from happening.
Basically, it'd be an absolute nightmare.
>Modern linux distros assume that everyone wants to run the
Distros often include a backports repository for stuff like that. And just because the current distros don't fit *your* needs, doesn't mean they don't fit the needs of the most people as far as packaging is concerned.
Bitten by the Red Hat Perl bug (InfoWorld) Posted Aug 29, 2008 15:35 UTC (Fri) by MattPerry (guest, #46341) [Link]
> So we'd be abolishing Linux distros and relying on upstream to package
> their software against the magical combination of libraries on your > system? Yeah, good luck with that happening.
If a distro is LSB compliant and the package is built to work on LSB compliant system, then there won't be a problem.
> You'd need all the repositories for all of the dependencies. You'd also
Again, LSB compliance. The packages are built to a standard and the distros support this standard. This isn't rocket science.
> Distros often include a backports repository for stuff like that.
So I have to depend on the distro maintainers to support older versions? Are there backports of every package in the repository? Are the repositories in the sources list by default?
> And just because the current distros don't fit *your* needs, doesn't
Just because they do fit your needs doesn't mean they fit the needs of most people as far as packaging is concerned.
Bitten by the Red Hat Perl bug (InfoWorld) Posted Aug 29, 2008 21:11 UTC (Fri) by Sutoka (guest, #43890) [Link]
>If a distro is LSB compliant and the package is built
>to work on LSB compliant system, then there won't be a problem.
So now no software can have dependencies on software not included in the LSB? Or are all non-LSB dependencies going to have to be statically compiled in or shipped with the package in some way? Neither of those are a very nice solution... If you don't do either, you just push the problem up slightly higher.
>Just because they do fit your needs doesn't mean they fit
Quite few people complain about the current system, and lots of people tout the current system as being one of Linux's big advantages. This is while lots of people complain about how it works on Windows, with most software not having any auto update mechanism, and the developers that do each have their own implementation (Windows Update vs Adobe Updater vs Steam vs Firefox's vs etc).
Bitten by the Red Hat Perl bug (InfoWorld) Posted Aug 29, 2008 17:18 UTC (Fri) by vonbrand (subscriber, #4458) [Link] What is easier is that one can upgrade their operating system or the application independent of each other without having to learn the details of system administration. Right now, if I want a new version of Firefox, I have to upgrade my entire operating system which I do not want to do. This will also upgrade all of the other packages on my system. That's a big change just to get a new version of one program.
That's called "dependencies", i.e., shiny new <foo> package needs new The price you pay for fast, solid progress is that old code is just left behind. Just like a stable API in the kernel is nonsense, it applies in userland.
|
|||||||||||||