fonts packaging guidelines, or advices?
by Patrice Dumas
Hello,
I think it could be helpful to have some guidelines regarding fonts. I
guess people specialized in fonts packaging are allready following more
or less formal rules, but I have felt the need for guidelines when I
package something and it has fonts within, or when there is a need for
some fonts in a package.
A font SIG or something similar than what is found at Packaging/Perl
could be enough, since the lack may be more about a lack of information
regarding font packaging than about a lack of formal rules, although
I think that some advice could be best practices and then guidelines.
What would be interesting in my opinion would be:
- advices on when to package fonts and when not to package them
- advice on acceptable font uses, depending on the font (I guess that
bitmap fonts, truetype and Type? fonts shouldn't be used for the same
tasks)
- when to do subpackages
- advice on fonts installation location (to my knowledge there is
nothing on that subject in the FHS), depending on the font.
- scriptlets for all the kind of fonts (truetype, Type? and bitmap) with
more explanations about the scriptlets than what is today. An
explanation on what subsystem begins aware of which font after which
scriptlet is run would be a must in my opinion.
- explanation on how to avoid messing with fonts provided in other packages
Something along what is done for rpath, for example could be very
usefull in my opinion, especially now that all the core package
containing fonts are to be reviewed.
It may be possible that even more coordination that packaging best
practices are needed, to avoid messing with others fonts, I don't know
the underlying technology enough, but some mail exchanges on (if I
recall well on the fedora-devel-list) makes me think that way.
Guidelines would certainly be a good start.
--
Pat
17 years, 3 months
Guidelines and epochs
by Axel Thimm
Seems like it isn't really clear that we want packagers to evoid
epochs like the devil. There are some situations that require epochs,
when there is no other way to undo versioning and, of course, when
there were epochs to start with.
Currently epochs are only mentioned under the Requires section:
> Second, the Epoch must be listed when adding a versioned dependency
> to achieve robust epoch-version-release comparison. A quick way to
> check the Epoch of package foo is to run:
I'd like to clarify that so that it refers only to non-zero epochs to
avoid people adding "0:" upfront of every mentioned version(-release),
e.g. change "the Epoch" against "a non-zero Epoch"
Then I'd like to have somewhere a recommendation that epochs should be
avoided as much as possible. This seems to belong to
Packaging/NamingGuidelines, where epochs seem to have been left off
(probably deliberately to not lead people into temptation). How about
> Package Epoch
>
> epochs are generally to be avoided. They provide a last-resort
> mechanism to override package version and release, but are more
> trouble than they are worth while. If you realy have to use an epoch
> you MUST use a simple integer (technically anything that is suited
> for the version/release tags is also suited here). Make sure you
> explore all other possiblities before deciding to use epochs.
--
Axel.Thimm at ATrpms.net
17 years, 3 months
Acceptability of "content" in merged Fedora
by Jason L Tibbitts III
The guidelines include the following statement in the "Code
Vs. Content" section:
"Note, content is only acceptable within Fedora Extras, not Core."
I'm not sure why content isn't permissible in Core, but we need to
figure out if the restriction will apply to the new Fedora and change
the guidelines appropriately.
So, why was content not permissible in Core?
- J<
17 years, 3 months
Request to drop %(%{__id_u} -n) in preferred buildroot
by Axel Thimm
Hi,
I think the `preferred buildroot' is not really making sense. The
above has developed historically out of a misunderstanding in ancient
buildroot times.
When people were building as root and BuildRoots were defined as
%{_tmppath}/%{name}-%{version}-root, some considered "root" to mean
the uid of the builder. Later %release was added and some replaced
root with `id -un`. Even later some realized that root was referring
to the BuildRoot and in order to play safe added both.
I'm using %{_tmppath}/%{name}-%{version}-%{release}-root in my
packages and someone is now nitpicking on why not using the preferred
BuildRoot as given in the guidelines. Instead of locally fighting a
BuildRoot battle, I'd better get the guidelines fixed ;)
Also consider what this really is about: Deambiguifying the BuildRoot
per package makes sense as there may be several build processes
sharing the same filesystem (either locally or through NFS), but
deambiguifying the build user, too, means that we assume that the same
EVR package will be possibly built on the same filesystem by
different users? And even simultaneously?
It makes more sense to include a conditional epoch or target/arch in
the buildroot that the builder. In fact the best thing for a
buildsystem is to override the buildroot adding a build-id to it
anyway.
--
Axel.Thimm at ATrpms.net
17 years, 3 months
iconcache, v0.5
by Rex Dieter
FYI, updated iconcache proposal v0.5:
* nixed xdg-utils.
* Updated motivations/justifications,
* gtk2 implementation suggestions/links,
http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
Looks like Core folks won't settle for anything in between status-quo
and 100% fix (no in-between-compromising like using xdg-utils), so let's
give it a shot.
This time round, I'll try to put all relavent suggestions, comments,
dialog on the wiki. Hopefully, that will help keep those not following
the intimate details of the ml threads informed.
-- Rex
17 years, 3 months
