On Tue, 2012-02-07 at 13:51 +0530, Rahul Sundaram wrote:
>
>
> On Tue, Feb 7, 2012 at 12:38 PM, Bohuslav Kabrda <bkabrda@redhat.com>
> wrote:
>
>
> Again, citing FHS:
> "Distributions may install software in /opt, but must not
> modify or delete software installed by the local system
> administrator without the assent of the local system
> administrator."
>
>
> How can this be interpreted as "non-OS vendor supplied"?
>
> This is one of many places in which FHS is vague but that's the common
> interpretation all distributions rely on

Um. Really? Wasn't there a distro - I'm thinking SUSE? - that installed
KDE in /opt for a long time?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On Tue, Feb 7, 2012 at 1:25 PM, Adam Williamson <awilliam@redhat.com> wrote:
> On Tue, 2012-02-07 at 13:51 +0530, Rahul Sundaram wrote:
>>
>>
>> On Tue, Feb 7, 2012 at 12:38 PM, Bohuslav Kabrda <bkabrda@redhat.com>
>> wrote:
>>
>>
>> * * * * Again, citing FHS:
>> * * * * "Distributions may install software in /opt, but must not
>> * * * * modify or delete software installed by the local system
>> * * * * administrator without the assent of the local system
>> * * * * administrator."
>>
>>
>> * * * * How can this be interpreted as "non-OS vendor supplied"?
>>
>> This is one of many places in which FHS is vague but that's the common
>> interpretation all distributions rely on
>
> Um. Really? Wasn't there a distro - I'm thinking SUSE? - that installed
> KDE in /opt for a long time?
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
> http://www.happyassassin.net
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

Suse is technically closer to the original intent of the filesystem
hierarchy standard. /usr/bin is for non-critical system binaries (on
some Unix installations, /usr/bin is mounted readonly via NFS).
/usr/local and /opt would then be used to hold optional packages.


--
Mark Bidewell
http://www.linkedin.com/in/markbidewell
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On 02/07/2012 11:55 PM, Adam Williamson wrote:
> On Tue, 2012-02-07 at 13:51 +0530, Rahul Sundaram wrote:
>>
>>
>> On Tue, Feb 7, 2012 at 12:38 PM, Bohuslav Kabrda <bkabrda@redhat.com>
>> wrote:
>>
>>
>> Again, citing FHS:
>> "Distributions may install software in /opt, but must not
>> modify or delete software installed by the local system
>> administrator without the assent of the local system
>> administrator."
>>
>>
>> How can this be interpreted as "non-OS vendor supplied"?
>>
>> This is one of many places in which FHS is vague but that's the common
>> interpretation all distributions rely on
>
> Um. Really? Wasn't there a distro - I'm thinking SUSE? - that installed
> KDE in /opt for a long time?

Not anymore apparently

Rahul

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Here is the latest set of changes to the Fedora Packaging Guidelines:

---

A bundling exception for boost within Passenger was granted, due to the
intrusive nature of the forked changes, the efforts of the maintainer to
merge as many of them as possible into the upstream boost source tree,
and the visible efforts of the upstream to keep the bundled copy of
boost in sync with the current boost releases.

The package must also include a Requires: bundled(boost) = $VERSION
where $VERSION is the boost version being bundled.

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_ex ceptions

---

Packages which have SysV initscripts that contain 'non-standard service
commands' (commands besides start, stop, reload, restart, or
try-restart) must convert those commands into standalone helper scripts.
Systemd does not support non-standard unit commands.

https://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files

---

A section was added to the systemd Packaging Guidelines page with a link
to the Tmpfiles.d Packaging Guidelines page, since systemd uses Tmpfiles.d.

https://fedoraproject.org/wiki/Packaging:Systemd#Tmpfiles.d

---

The Ruby Packaging Guidelines were almost completely rewritten. If you
maintain ruby packages in Fedora, we advise that you review the new
guidelines.

https://fedoraproject.org/wiki/Packaging:Ruby

---

An informational note about Software Collection macros in Fedora
Packages was added:

https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macros

---

The guidelines relating to PIE and Hardened Packages were updated. Now,
if your package meets the following critera you MUST enable the PIE
compiler flags:

* Your package is long running. This means it's likely to be started and
keep running until the machine is rebooted, not start on demand and quit
on idle.

* Your package has suid binaries, or binaries with capabilities.

* Your package runs as root.

https://fedoraproject.org/wiki/Packaging:Guidelines#PIE

---

Rules involving appropriate scripting within Fedora Package spec files
were added to the Guidelines:

https://fedoraproject.org/wiki/Packaging:Guidelines#Scripting_inside_of_spec_file s

---

The section in the systemd guidelines covering EnvironmentFiles and
support for /etc/sysconfig files was revised for clarification.

https://fedoraproject.org/wiki/Packaging:Systemd#EnvironmentFiles_and_support_for _.2Fetc.2Fsysconfig_files

---

The Ada Packaging Guidelines were updated for new rules on packaging
source files and updated macros.

https://fedoraproject.org/wiki/Packaging:Ada

---

The section of the Packaging Guidelines describing the "bootstrapping"
binary exception was amended for clarification:

https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions

---

The section of the Packaging Guidelines describing Duplication of system
libraries was amended to clarify the exceptions for Javascript and
parallel stacks.

https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_librari es

---

These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).

Many thanks to Kevin Fenzi, Bohuslav Kabrda, Brett Lentz, Marcela
MaÅ¡láňová, Bill Nottingham, VÃ*t Ondruch, Mamoru Tasaka, and all of the
members of the FPC, for assisting in drafting, refining, and passing
these guidelines.

As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure

Thanks,

~tom
_______________________________________________
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Tom Lane (tgl@redhat.com) said:
> Tom Callaway <tcallawa@redhat.com> writes:
> > Here is the latest set of changes to the Fedora Packaging Guidelines:
> > ---
> > Packages which have SysV initscripts that contain 'non-standard service
> > commands' (commands besides start, stop, reload, restart, or
> > try-restart) must convert those commands into standalone helper scripts.
> > Systemd does not support non-standard unit commands.
>
> I was a bit surprised to read this, because in recent versions systemd's
> service command supports nonstandard verbs just fine; it'll pass an
> unrecognized verb through to the initscript, if there is one. Is that
> functionality going to be removed again?
>
> Background: after having done what the above text directs me to,
> I had gotten beaten up over the fact that "service postgresql initdb"
> no longer worked, and hence reinstituted a stub initscript that only
> handles the nonstandard actions of the old one. Which works fine, or
> at least it did as of last month when I last tried it. So now I'm in
> violation of the guidelines for having tried to keep my users happy,
> and I'm not happy, especially since the stated rationale is a falsehood.

If you're asking if that bit of /sbin/service is going to be removed
(redirection to /etc/init.d/<foo> for nonstandard commands), no.

Bill
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

On 04/12/2012 05:19 PM, Tom Lane wrote:
> Background: after having done what the above text directs me to,
> I had gotten beaten up over the fact that "service postgresql initdb"
> no longer worked, and hence reinstituted a stub initscript that only
> handles the nonstandard actions of the old one. Which works fine, or
> at least it did as of last month when I last tried it. So now I'm in
> violation of the guidelines for having tried to keep my users happy,
> and I'm not happy, especially since the stated rationale is a falsehood.

systemd doesn't understand non-standard commands. "service" passes
through, but that was determined to be confusing.

If you want to make an initscript stub, you can, but it needs to be in a
separate subpackage, per the guidelines. We're trying not to have unit
files and sysv initscripts in the same package, whether they're stubs or
not.

~tom

==
Fedora Project
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

On 04/13/2012 10:58 AM, Tom Lane wrote:
> Well, if it has to be in a new subpackage then I'm just going to drop it.
> The entire rationale for the stub was to make things "just work" for
> people who don't read the release notes. If it requires they install
> a new subpackage they never heard of before, that would still require
> reading the release notes, so it's not helpful. (Unless I was to make
> postgresql-server require the new subpackage, but I'm sure that would
> not be considered good packaging practice either ...)

I understand what you're saying here. I think dropping the stub is the
best path forward here, along with making sure that the new "helper"
commands are in the release notes.

~tom

==
Fedora Project
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Tom Callaway (tcallawa@redhat.com) said:
> On 04/13/2012 10:58 AM, Tom Lane wrote:
> > Well, if it has to be in a new subpackage then I'm just going to drop it.
> > The entire rationale for the stub was to make things "just work" for
> > people who don't read the release notes. If it requires they install
> > a new subpackage they never heard of before, that would still require
> > reading the release notes, so it's not helpful. (Unless I was to make
> > postgresql-server require the new subpackage, but I'm sure that would
> > not be considered good packaging practice either ...)
>
> I understand what you're saying here. I think dropping the stub is the
> best path forward here, along with making sure that the new "helper"
> commands are in the release notes.

My concern would be that we should likely standardize on a format/invocation
for new helper commands wherever possible. Do we have existing ones outside
of iptables at this point?

Bill
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

On 04/13/2012 11:33 AM, Bill Nottingham wrote:
> Tom Callaway (tcallawa@redhat.com) said:
>> On 04/13/2012 10:58 AM, Tom Lane wrote:
>>> Well, if it has to be in a new subpackage then I'm just going to drop it.
>>> The entire rationale for the stub was to make things "just work" for
>>> people who don't read the release notes. If it requires they install
>>> a new subpackage they never heard of before, that would still require
>>> reading the release notes, so it's not helpful. (Unless I was to make
>>> postgresql-server require the new subpackage, but I'm sure that would
>>> not be considered good packaging practice either ...)
>>
>> I understand what you're saying here. I think dropping the stub is the
>> best path forward here, along with making sure that the new "helper"
>> commands are in the release notes.
>
> My concern would be that we should likely standardize on a format/invocation
> for new helper commands wherever possible. Do we have existing ones outside
> of iptables at this point?

We attempted to do this at the same time, but we couldn't come up with
anything sane or obvious. If you can, we'd welcome it.

~tom

==
Fedora Project
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

On 04/14/2012 02:32 PM, Jeroen van Meeuwen wrote:

On Thursday, April 12, 2012 04:57:29 PM Tom Callaway wrote:

A bundling exception for boost within Passenger was granted, due to the
intrusive nature of the forked changes, the efforts of the maintainer to
merge as many of them as possible into the upstream boost source tree,
and the visible efforts of the upstream to keep the bundled copy of
boost in sync with the current boost releases.

The package must also include a Requires: bundled(boost) = $VERSION
where $VERSION is the boost version being bundled.

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_grant
ed_exceptions



While I appreciate the work Brett Lentz has been putting in upstream, why does
this package have to be taken away from me?

I'm already facing a "thanks for your work but no thanks"[1].

I respectfully request Uncle Shadowman *not* be forcefully made the owner of
the package, and the reporter of the review request be granted ownership.

Kind regards,

Jeroen van Meeuwen

[1] https://bugzilla.redhat.com/show_bug.cgi?id=470696#c114


No need for this to be mutually exclusive, unless one (or both) of you
are averse to being comaintainers?


-- rex
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging