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

Per
http://fedoraproject.org/wiki/Extras/FedoraDesktopEntryGuidelines:
The vendor prefix (desktop-file-install --vendor=...) must be set to
fedora".
I don't understand the rationale/motivation behind requiring '--vendor
fedora'
I can, however, see that desktop-file-install's current
implementation(*) of prepending %{vendor}- to the .desktop file name has
some problems/issues:
1. .desktop filename now varies from upstream
2. --vendor may change when/if Extras bits are pulled into Core and/or
RHEL.
3. *In particular*: when users start employing menu editors, since
most(all?) of them base their customizations on the .desktop file name.
-- Rex
(*) If desktop-file-install's implementation instead followed something
like kde's practice of using a vendor directory (e.g.
/usr/share/applications/kde), then (1) and (3) would no longer be an issue.

As you are all probably intimately aware by now, there has been
discussions about 3rd party repositories overriding base Fedora
packages and creating their own distribution which causes very serious
problems for users and damages the community.
I suggest that we have a comittee (possibly the packaging comittee)
create a wiki page which reviews 3rd party repositories for such
things as:
- Does the repository have a review process
- Does the repository abide by Fedora packaging standards
- Does the repository override Fedora base packages
and possibly other criteria.
This will allow users to see which 3rd party repositories play nice
with Fedora, and which ones fork Fedora to create their own
distributions, etc.
I FIND IT *VERY* DISTRUBING THAT ONE OF THESE REPOSITORY MAINTAINERS
IS ON THE FEDORA PACKAGING COMITTEE!
Here is an example IRC log that was taken just last night illustrating
the problem:
20:40:49 RyeBrye | Trying to get yum to install gtk2-devel
from the update repo I get 4 dependency errors
20:41:10 RyeBrye | the first one is gtk2 itself
20:41:17 XulChris | RyeBrye: caused by using atrpms no doubt
20:41:25 RyeBrye | hm
20:41:34 RyeBrye | How can I tell which packages I have
installed that came from atrpms?
20:42:00 XulChris | RyeBrye: disable the atrpms repo, and run
"yum list extras"
20:43:42 RyeBrye | I'm relatively new to Linux - but it seems
that the prevailing opinion is that atrpms = the devil
20:44:23 XulChris | RyeBrye: basically yes, we even attempted to
tell AT this, but he refused to listen and accused of of using "FUD"
techniques against his
repository
20:44:40 RyeBrye | Oh. AT is a person?
20:44:46 XulChris | Axel Thimm
20:45:49 XulChris | RyeBrye: we are trying to put measures in
place to prevent repositories from doing this
20:45:59 XulChris | see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211250
20:50:06 RyeBrye | Sounds like I should get that "priorities"
plugin for yum going to prevent atrpms from going buck-wild installing
packages
20:50:39 errr | oh boy, more atrpms "fud" :P
20:50:52 XulChris | RyeBrye: yea, or if you just need a single
rpm, try installing it by hand using the rpm command instead of yum,
and if it doesnt install, get
the srpm file and rebuild the rpm from the srpm
20:51:08 XulChris | errr: lol
20:51:27 errr | that was really getting funny in my inbox
the other day
20:51:53 XulChris | ya, what did we get? like 80 messages within
24 hours? :)
20:52:00 errr | maybe more
20:52:00 errr | lol
20:52:04 XulChris | hehe
20:52:11 * rewster is pretty sure atrpms' rpm for Myth doesn't
build as-is on stock fedora
20:53:51 * RyeBrye is busy removing a whole lot of crap because
atrpms installed a gtk2 package - and just about everything he
installed from atrpms (mythtv)
depended on it
20:53:56 rewster | err srpm. and I think the OP mentioned
having AT for myth.
20:54:18 RyeBrye | or rather... yum is busy removing it
20:54:20 rewster | yeah... which is a bummer. A lot of the
faqs for myth just say "use atrpms"
22:09:56 RyeBrye | ATRpms really f*'ed up my system... it
installed a gtk2 that - when I removed it - removed just about every
darn package I had installed
because of dependencies... argggggg
22:10:18 EvilBob | RyeBrye: file a bug with them
22:10:24 autopsy | RyeBrye, don't use ATrpms.
22:10:27 siXy | again?
22:10:28 EvilBob | RyeBrye: PLEASE
22:10:42 errr | lol
22:10:49 RyeBrye | I'm learning my lesson...
22:10:56 RyeBrye | Does livna really have mythtv rpms?
22:10:59 siXy | or are you reffering to the first time?
22:11:02 siXy | no
22:11:05 EvilBob | RyeBrye: sorry you got burned but the
maintainer insists that there is not a problem with how he does things
22:11:12 errr | does Alex never come to this IRC?
22:11:24 autopsy | You mean Axel.
22:11:26 siXy | axel is an interesting guy...
22:11:28 EvilBob | errr: Alex who?
22:11:34 RyeBrye | Why doesn't he just make his own damned distro! argh
22:11:40 XulChris | EvilBob: axel thimm (AT)
22:11:43 errr | autopsy: oh maybe I do
22:11:45 siXy | some would say he does
22:11:50 EvilBob | RyeBrye: add that to your bug
22:12:20 errr | I dont follow the room all that close but
at least once or twice a week I notice someone in here with the ATrpms
sobstory
22:12:52 siXy | but anyways - do like i told you and
update, then enable atrpms grab myth and its explicit dependancies
then delete the atrpms repo
22:13:13 RyeBrye | siXy - yeah, you are right
22:13:31 EvilBob | never ever update with atRPMs enabled
22:13:44 siXy | its important you update fist tho otherwise
when you grab myth that will pull some atrpms pacakges that you really
dont want
22:14:11 RyeBrye | is there a way to update without it loading
a new kernel? I don't feel like rebuilding all my kernel extensions at
the moment
22:14:53 siXy | RyeBrye: do you have a copy of that line to
remove all atrpms pacakges? was trying to remember it earlier for
someone else
22:14:53 chemaja The bz that XulChris pointed us to
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211250) will be
the key once it is implemented.

This just adds noise and cruft to desktop files and spec files. It is not
used by anything.
Likewise --vendor fedora, but current desktop-file-install requires a vendor
even though it isn't in use. We'll be fixing that shortly though.
So for now, can I get votes to remove the --add-category X-Fedora line from
the guidelines?
For the --vendor thing, it should probably stay in for now for older releases
since I don't want to see our guidelines get too broken up between what is
allowed or disallowed per release.
--
Jesse Keating
Release Engineer: Fedora

On Mon, Oct 23, 2006 at 03:04:30PM -0400, Alan Cox wrote:
> /srv is ridiculous from any sane interpretation. It got in purely because
> the people actually doing useful work accidentally briefly got outnumbered
> by people with no experience and opinions when it was voted on
Well, I certainly don't have your experience.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>

On Thu, Oct 19, 2006 at 02:32:20PM -0600, Stephen John Smoogen wrote:
> On 10/19/06, J French <me(a)semitekie.com> wrote:
> >Just wondering if there's any intention of moving the default locations
> >for Apache's webroot and database files (MySQl, Postgres, et al) to /srv
> >where they belong.
> >
>
> Well it could be possible, but the /srv section is left up to the
> individual site to dictate layout and not the vendor (if I read the
> FHS correctly.
That's correct. Furthermore the FHS supports different hierarchies
below /srv depending on the site's needs. For example a server hosting
project1.org and project2.org would use
/srv/project1.org/www and
/srv/project2.org/www
So /srv should be kept free of any package bits. I'm copying the
packaging list, perhaps it's worth noting in the guide.
--
Axel.Thimm at ATrpms.net

I'd like to request the following packaging policy:
[...]
If a packager uses something with the same effect than
%define debug_package %{nil}
which disables the automatically built "debuginfo" package, the spec file
MUST contain a comment that explains why this is done.