On Monday 10 November 2003 12:47 pm, Michael Schwendt wrote: > Worse than that. It's missing the point. The different repositories don't > advertise any differences between multiple packages of the same > software. That's what the repository tag in the release is for. And that's what changelogs are for. > problems. For Joe User to be able to choose between multiple packages of > the same software, he must know whether there are meant to be differences. > E.g. but not limited to preconfiguration, desktop integration, > initscripts, helper scripts. These are all documentation problems, not packaging issues. > included in the source tarball provided upstream. Most package > differences, e.g. package names, spec file formatting issues or > conditional build options, are only cosmetic and pretty much > irrelevant. The usual package differences are accidental, e.g. incomplete > or incorrect dependencies, wrong file access permissions, missing files or > links. Conditional build options are not cosmetic if you are building for many OS versions. As to formatting, whose format is correct? Yours? Accidental differences are bugs, for sure. But I'm sure there are intentional differences, and that's where choice (packager's choice) comes in. > > Some repos repackage stuff built a different way because their > > packager wants to build it a different way. That is their choice; and > > users are free to choose to not use them. > This is a major problem when multiple repositories don't work together. When a user chooses free software, then that user must take the responsibility for that choice. In this case, that means the user has the responsibility of choosing a repository that fits that user's needs. This may take more than one iteration to perform. But that just goes with the Open Source territory. Freedom comes with responsibilities. Which is why some people choose to give up their freedom and go with a system where there is less choice. I prefer being able to make an informed choice; but that isn't everyone's preference. That having been said, it would be nice to have a modicum of compatibility; but I am seeing an extended argument on why there has to be only one way to do it, when everybody knows TMTOWTDI. Sure, Debian has a central repository, but there are third party sources of packages for Debian. But then again Debian includes _everything_ in their distribution, making a third party repository much less attractive. Plus, RPM based distributions apparently are more popular, creating the desire for third party repos when the main Core doesn't have what the user wants. And I repeat: if I set up a repository on my machine using my electricity, time, and bandwidth, I will do it however I want to do it. If that means I cooperate with others, so be it (and I'm the type that prefers to cooperate). But if I disagree I reserve the right to do it my way on my property. If you don't like the way I do it, then don't use my repository. Pretty simple. If users use my repository and like it, I must be doing something right, no? (FreshRPMs is one such repository; people use it, like it, and it works, regardless of who argues that Matthias is Doing Things the Wrong Way.) And if I happen to be the only repository that has package foo-bar-baz.x.y-z compiled with your favorite options, then you have a decision to make: is the convenience of having foo-bar-baz worth dealing with my repository's potential incompatibilities. In my case, while I don't agree with everything Matthias does in packaging, his packages do mostly the right thing. Axel's repository is a sweet spot for other needs (like precompiled kernels with V4L2 support). But I cannot reasonably demand that Axel and Matthias must work together for my convenience if they do not want to work together. Unless I want to pay their bills, that is. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
