On Thu, Dec 01, 2005 at 07:36:53AM -0800, Jesse Keating wrote: > On Thu, 2005-12-01 at 12:36 +0100, Axel Thimm wrote: > > I really wonder what makes accepting "package replacements" so hard, > > when you accept "kernel functionality replacement". If I were to fear > > about destabilisation of my system, then I would place avoiding kernel > > modules at number 1. > > > > But no, some are upset that libtool gets replaced, but they happily > > effectivly replace their kernel modules. And are even (obviously) > > using the testing repo from ATrpms, as the kernel modules you want are > > in there. > > > > The real issue here is that the user wants one little thing from AT. > They want to try out an experimental test module for a piece of > hardware. They don't want to replace many core packages. They get > frustrated when they want to install this little thing and they get a > rather confusing dep list. Same with updates-testing. If you simply activate updates-testing, because there is a nice pacxkage update you have been waiting for, then you either get the whole bunch, or you need to figure out the dependencies yourself. > Just why do you force your replacement packages on users? Nobody forces anyone. The argument that seems to drift away is that if you don't like a subset of a repo and use tools like apt and smart to automatically filter out some packages, other packages will break if depedending on functionality of the filtered out package. So it's either dropping the repo altogether or figuring out the (functional!) dependencies manually. I just don't want get bug reports, because a user filtered out the upgrade of package bar needed for package foo. > What is it about your replacement core packages that are so much > better for Core users that anybody who uses any of your rpms must > have all those replacements?[1] It depends on the package. Some dependencies require activating more build configure options & BuildRequires, others a newer version. There is no general rule of thumb, and I certainly don't try to kill my time by unneccessary work. > It seems to me that you're just waving your hand over it and saying > "oh they're fine... don't worry about those..." You're saying that > if you want to use a experimental module (and possibly remove it > right directly) well too bad, you have to have all these packages > too, and you have to like it. Is that what updates-testing is saying? Show me the solution there and I'll take it over for atrpms-testing. If you want to only test the latest testing kernel but not gcc/whathever you will face the same situation, either upgrade to all in updates testing, or pull down only the package(s) you need and possibly some further dependencies found there. Do the same with ATrpms and any other repo, you want. You wouldn't use apt's and smart's automated weighing alghorithms on updates-testing for the very same reasons I recommend not to use them on anything else. > [1] It has been a while since I used any AT rpms. I don't know if > it is still the case that one AT package would mean replacement of a > lot of Core packages anymore. I'm just going by other people's > emails and your responses. Well, w/o even testing the repo and its contents how can you make a statement on whether and which packages are unneccessary updates, and whether or not stability of your system is at stake? -- Axel.Thimm at ATrpms.net
Attachment:
pgpJDDNlccusl.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
