Re: spec file changes: removing Release: and %changelog

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux