On Thu, 2008-03-06 at 00:32 +0000, Daniel P. Berrange wrote: > The hal example is utterly disgusting You have looked at the existing hal.spec, right? I don't think any version of hal packaging is going to be pretty, at least if you're operating under the constraint of generating compatible RPMs. The hal-libs split is weird, and the architecture deps are a mess. Though the latter could be cleaned up with a dpkg-like mini-language for them perhaps instead of arbitrary code. > This looks like completely the wrong way to solve the copy+paste scriptlets > problem. Turning a declarative configuration format into a programming > language simply to eliminate common config is just nuts. It's just as declarative as spec files are. Which is to say, it's mixed. > If we want to eliminate the common scriptlets, then RPM should get richer > metadata. By auto-generating the spec files from python you're just pushing > the problem elsewhere Right - onto people who care about them and know the details, not the responsibility of someone who wants to add a new package that happens to use a desktop file. > & whenever the python wrapper needs to change the > scriptlets you need to re-generate all the distro's spec files / RPMS. Nothing about this approach would preclude installing the scripts system wide and generating code to call them. I think that's actually a good idea - we tried to do that with desktop-file-install, for example. > The vast majority of scriptlets can be eliminated if RPM knew what the > file type is - eg, if it sees an ELF library, it should automatically > run ldconfig. If it see a desktop file it should automatically run > the desktop file install script, etc, etc. If done right you can add > more scriptlets / change existing scriptlets for any existing RPM > without needing to re-generate the RPM / spec. Honestly, I don't have a strong opinion on which layer in the system this intelligence should live. If the RPM maintainers think that it belongs in RPM, that's fine by me. I think we all do agree that we want a more automatic system with possible overrides. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
