I'm looking into packaging gtypist, which has an emacs add-on: gtypist-mode.{el,elc}
I'd like to just put %{_datadir}/emacs/site-lisp/* in %files and be done with it but this seems to go in direct opposition to the following:
================================================================ http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. The exception to this are directories listed explicitly in the Filesystem Hierarchy Standard ([WWW] http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that those directories exist.
MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. =================================================================
So I can (in my personal ascending in preference):
1. Require: emacs (this doesn't seem reasonable for people who don't use emacs since the lisp add-ons are usually optional) 2. do something like cscope and use triggers (just say no to triggers). 3. create a sub-package just for the emacs lisp add-on. (seems cleanest, but is there a naming guideline for this situation? What would the name be? Is this worth the effort?)
or... 4. Can I just go ahead with %{_datadir}/emacs/site-lisp/*? :)
zing
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Zing wrote:
I'm looking into packaging gtypist, which has an emacs add-on: gtypist-mode.{el,elc}
I'd like to just put %{_datadir}/emacs/site-lisp/* in %files and be done with it but this seems to go in direct opposition to the following:
================================================================ http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. The exception to this are directories listed explicitly in the Filesystem Hierarchy Standard ([WWW] http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that those directories exist.
MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. =================================================================
So I can (in my personal ascending in preference):
- Require: emacs (this doesn't seem reasonable for people who
don't use emacs since the lisp add-ons are usually optional) 2. do something like cscope and use triggers (just say no to triggers). 3. create a sub-package just for the emacs lisp add-on. (seems cleanest, but is there a naming guideline for this situation? What would the name be? Is this worth the effort?)
or... 4. Can I just go ahead with %{_datadir}/emacs/site-lisp/*? :)
Use triggers and ghost the emacs/xemacs directories. For an example see the fedora-rpmdevtools specfile.
jpo - -- José Pedro Oliveira * mailto: jpo@di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B *
On Tue, 2006-06-06 at 01:10 +0100, Jose Pedro Oliveira wrote:
So I can (in my personal ascending in preference):
- Require: emacs (this doesn't seem reasonable for people who
don't use emacs since the lisp add-ons are usually optional) 2. do something like cscope and use triggers (just say no to triggers). 3. create a sub-package just for the emacs lisp add-on. (seems cleanest, but is there a naming guideline for this situation? What would the name be? Is this worth the effort?)
or... 4. Can I just go ahead with %{_datadir}/emacs/site-lisp/*? :)
Use triggers and ghost the emacs/xemacs directories. For an example see the fedora-rpmdevtools specfile.
Or:
Create a sub-package for the emacs lisp add-ons. Naming guideline for this situation is here:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#AddonEmacs
I think I'd prefer that over triggers, but either will probably pass review.
~spot
On Tue, Jun 06, 2006 at 08:27:37AM -0500, Tom 'spot' Callaway wrote:
On Tue, 2006-06-06 at 01:10 +0100, Jose Pedro Oliveira wrote:
Use triggers and ghost the emacs/xemacs directories. For an example see the fedora-rpmdevtools specfile.
Or:
Create a sub-package for the emacs lisp add-ons. Naming guideline for this situation is here:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#AddonEmacs
I think I'd prefer that over triggers, but either will probably pass review.
Linux Standard Base disallows the use of triggers (that's another argument against them).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tom 'spot' Callaway wrote:
On Tue, 2006-06-06 at 01:10 +0100, Jose Pedro Oliveira wrote:
So I can (in my personal ascending in preference):
- Require: emacs (this doesn't seem reasonable for people who
don't use emacs since the lisp add-ons are usually optional) 2. do something like cscope and use triggers (just say no to triggers). 3. create a sub-package just for the emacs lisp add-on. (seems cleanest, but is there a naming guideline for this situation? What would the name be? Is this worth the effort?)
or... 4. Can I just go ahead with %{_datadir}/emacs/site-lisp/*? :)
Use triggers and ghost the emacs/xemacs directories. For an example see the fedora-rpmdevtools specfile.
Or:
Create a sub-package for the emacs lisp add-ons. Naming guideline for this situation is here:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#AddonEmacs
I think I'd prefer that over triggers, but either will probably pass review.
If you are talking about installing only one file like
* emacs/xemacs mode file * emacs/xemacs init file * vim files (eg: syntax file) * bash-completion file
it appears to me a little overkill to create a subpackage but I am opened to suggestions.
Right now, almost every package that installs the above files appears to do so in different ways.
Just try to see who owns the directories
* rpm -qf /etc/bash_completion.d/ bash-completion-20060301-1.fc5 rpmlint-0.76-1.fc5
* rpm -qf /usr/share/emacs/site-lisp/ desktop-file-utils-0.10-6.1 libidn-0.6.2-1.1 autoconf-2.59-7 gforth-0.6.2-6.fc5 subversion-1.3.1-2.1 fedora-rpmdevtools-1.6-1.fc5 emacs-common-21.4-14 asymptote-1.06-5.fc5
* ... xemacs ...
* ... vim ...
and how many files are symbolic links.
- -- José Pedro Oliveira * mailto: jpo@di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B *
On Tue, 2006-06-06 at 16:53 +0100, Jose Pedro Oliveira wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tom 'spot' Callaway wrote:
On Tue, 2006-06-06 at 01:10 +0100, Jose Pedro Oliveira wrote:
So I can (in my personal ascending in preference):
- Require: emacs (this doesn't seem reasonable for people who
don't use emacs since the lisp add-ons are usually optional) 2. do something like cscope and use triggers (just say no to triggers). 3. create a sub-package just for the emacs lisp add-on. (seems cleanest, but is there a naming guideline for this situation? What would the name be? Is this worth the effort?)
or... 4. Can I just go ahead with %{_datadir}/emacs/site-lisp/*? :)
Use triggers and ghost the emacs/xemacs directories. For an example see the fedora-rpmdevtools specfile.
Or:
Create a sub-package for the emacs lisp add-ons. Naming guideline for this situation is here:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#AddonEmacs
I think I'd prefer that over triggers, but either will probably pass review.
If you are talking about installing only one file like
- emacs/xemacs mode file
- emacs/xemacs init file
- vim files (eg: syntax file)
My impression is that vim syntax files really need to be separate subpackages because the directory hierarchy they land in is versioned. Did you find a way around that? (Our discussion on IRC was cut short b/c of the FESCo meeting so I don't know if there's some neat trick you have in mind.)
- bash-completion file
it appears to me a little overkill to create a subpackage but I am opened to suggestions.
Overkill but arguably the cleanest.
Right now, almost every package that installs the above files appears to do so in different ways.
Just try to see who owns the directories
- rpm -qf /etc/bash_completion.d/ bash-completion-20060301-1.fc5 rpmlint-0.76-1.fc5
So this is the third (and deprecated?) method -- multiple owners of the directories.
On Tue, 2006-06-06 at 09:39 -0700, Toshio Kuratomi wrote:
So this is the third (and deprecated?) method -- multiple owners of the directories.
Owning directories is right out, because if/when rpm erase ordering is actually implemented correctly (at all?), this will be vital.
~spot
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Toshio Kuratomi wrote: [SINP]
- vim files (eg: syntax file)
My impression is that vim syntax files really need to be separate subpackages because the directory hierarchy they land in is versioned. Did you find a way around that?
I managed to come up with a couple of trigger scripts that allowed me to install the vim syntax files and still support vim updates although limited to vim 6.3, 6.4, and 7.0 (FC-3 .. FC-6).
The package ghosts the directories /usr/share/vim/vim{63,64,70} in order to avoid leaving unowned directories during vim upgrades or removals.
- bash-completion file
it appears to me a little overkill to create a subpackage but I am opened to suggestions.
Overkill but arguably the cleanest.
Yes. And you still haven't seen the scripts to install vim syntax files ;)
See the FE asymptote package (specfile also available here http://gsd.di.uminho.pt/jpo/software/fedora/asymptote.spec).
Again suggestions are welcome to avoid those fragile scripts.
Right now, almost every package that installs the above files appears to do so in different ways.
Just try to see who owns the directories
- rpm -qf /etc/bash_completion.d/ bash-completion-20060301-1.fc5 rpmlint-0.76-1.fc5
So this is the third (and deprecated?) method -- multiple owners of the directories.
jpo - -- José Pedro Oliveira * mailto: jpo@di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B *
On Tue, 2006-06-06 at 19:07 +0100, Jose Pedro Oliveira wrote:
- bash-completion file
it appears to me a little overkill to create a subpackage but I am opened to suggestions.
Overkill but arguably the cleanest.
Yes. And you still haven't seen the scripts to install vim syntax files ;)
See the FE asymptote package (specfile also available here http://gsd.di.uminho.pt/jpo/software/fedora/asymptote.spec).
Again suggestions are welcome to avoid those fragile scripts.
Icky :-( I can't think of a way to make them more robust, though.
I'd be inclined to make a subpackage for the vim syntax files. The emacs trigger scripts are reasonably understandable and work over a wide range of emacs versions (I haven't gone back far enough to find a RHL release on which they won't work.) If upstream vim keeps up their release pace, the vim trigger scripts will be broken within two years.
Additionally, the %ghost trick used for both vim and emacs cleanup will cause double ownership of directories which spot says is not just deprecated but a blocker.
-Toshio
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Toshio, [SNIP]
Additionally, the %ghost trick used for both vim and emacs cleanup will cause double ownership of directories which spot says is not just deprecated but a blocker.
Sorry but I disagree. Even (or better when) if rpm can remove packages in the correct order there are situations you can't avoid having two or more packages owning the same directory (for good examples check packages in the perl namespace).
jpo
PS - Several packages in the tetex namespace also own the same directories. - -- José Pedro Oliveira * mailto: jpo@di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B *
On Tue, 2006-06-06 at 20:04 +0100, Jose Pedro Oliveira wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Toshio, [SNIP]
Additionally, the %ghost trick used for both vim and emacs cleanup will cause double ownership of directories which spot says is not just deprecated but a blocker.
Sorry but I disagree. Even (or better when) if rpm can remove packages in the correct order there are situations you can't avoid having two or more packages owning the same directory (for good examples check packages in the perl namespace).
The only time we're permitting duplicate directory ownership is when there is not a clear dependency tree:
Package A uses /usr/foo to store files Package B uses /usr/foo to store files Neither package relies on anything that creates /usr/foo, and either package can be installed independently. Then, and ONLY then can both packages own /usr/foo.
~spot
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tom 'spot' Callaway wrote:
On Tue, 2006-06-06 at 20:04 +0100, Jose Pedro Oliveira wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Toshio, [SNIP]
Additionally, the %ghost trick used for both vim and emacs cleanup will cause double ownership of directories which spot says is not just deprecated but a blocker.
Sorry but I disagree. Even (or better when) if rpm can remove packages in the correct order there are situations you can't avoid having two or more packages owning the same directory (for good examples check packages in the perl namespace).
The only time we're permitting duplicate directory ownership is when there is not a clear dependency tree:
Package A uses /usr/foo to store files Package B uses /usr/foo to store files Neither package relies on anything that creates /usr/foo, and either package can be installed independently. Then, and ONLY then can both packages own /usr/foo.
What about these perl cenarios?
Perl module A::B Perl module A::B::C (and requires A::B)
1) Perl module A::B is a perl core module perl module A::B::C is not (CPAN)
Different directories trees (core vs vendor).
2) Both perl modules are CPAN modules with different perl(:MODULE_COMPAT_xxx) requirements
Vendor directory tree but different perl versions requirements.
3) Both perl modules are CPAN modules with the same perl(:MODULE_COMPAT_xxx) requirements
Removal order.
Perl module A::B::C should always own the A directory (also owned by A::B) or not ?
jpo jpo - -- José Pedro Oliveira * mailto: jpo@di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B *
On Tue, 2006-06-06 at 21:02 +0100, Jose Pedro Oliveira wrote:
What about these perl cenarios?
Perl module A::B Perl module A::B::C (and requires A::B)
Thus, whenever Perl module A::B::C is installed, A::B will already be there. If they have a common directory, A::B should own it, not A::B::C.
Perl module A::B::C should always own the A directory (also owned by A::B) or not ?
No. Package at the top of the dependency chain should own it. So, if A::B is the top, then it should own the A directory, since A::B::C can't go in without A::B.
~spot
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tom 'spot' Callaway wrote:
On Tue, 2006-06-06 at 21:02 +0100, Jose Pedro Oliveira wrote:
What about these perl cenarios?
Perl module A::B Perl module A::B::C (and requires A::B)
Thus, whenever Perl module A::B::C is installed, A::B will already be there. If they have a common directory, A::B should own it, not A::B::C.
Not true. Both modules need to own the A directory. The A directory may have different full paths or one of the modules A directory path may change in the future.
Perl module A::B::C should always own the A directory (also owned by A::B) or not ?
No. Package at the top of the dependency chain should own it. So, if A::B is the top, then it should own the A directory, since A::B::C can't go in without A::B.
Both modules need to own the A directory.
Assume again that we have two perl modules from CPAN
1) A::B 2) A::B::C which requires A::B
let's also assume that both modules were both build with the same perl version (eg: 5.8.8)
1) A::B owns the /usr/lib/perl5/vendor_perl/5.8.8/A directory
2) A::B::C only owns the /usr/lib/perl5/vendor_perl/5.8.8/A/B directory (as you want)
In a couple of months perl 5.8.9 gets released and a little latter one of the modules gets updated (let's assume A::B).
Now the module A::B gets rebuild and it now owns /usr/lib/perl5/vendor_perl/5.8.9/A
When you upgrade the module A::B the directory /usr/lib/perl5/vendor_perl/5.8.8/A will be unowned.
Remember that Fedora Core perl maintains several old perl paths in its directory search path. Just see the output of "perl -V" or print the value of the @INC array.
jpo - -- José Pedro Oliveira * mailto: jpo@di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B *
packaging@lists.fedoraproject.org