Updated rationales for specfile guidelines

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Updated rationales for specfile guidelines

Jan Engelhardt-4

Parts of the specfile guidelines have been just amended by me. It might
just be considered a redactional (linguistic) edit, but it feels too
much on either side of the fence, so here is an explicit notification
to those who care.


1. The section about $RPM_BUILD_ROOT was expanded/edited to list the
   shell vars (few and far) and reminding the reader that using them
   leads to disagreement with a sentence that was previously there:
   that mixing the styles should be avoided.

https://en.opensuse.org/index.php?title=openSUSE:Specfile_guidelines&diff=prev&oldid=121386


2. Rationale for rpm's offering of %__blah was updated, which leads to
   more emphasis avoiding %__ in openSUSE altogether:

https://en.opensuse.org/index.php?title=openSUSE%3ASpecfile_guidelines&type=revision&diff=121392&oldid=121390
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Updated rationales for specfile guidelines

Thorsten Kukuk
On Sun, Sep 03, Jan Engelhardt wrote:

>
> Parts of the specfile guidelines have been just amended by me. It might
> just be considered a redactional (linguistic) edit, but it feels too
> much on either side of the fence, so here is an explicit notification
> to those who care.

If somebody wonders about what this is:
I rejected package changes from Jan to my packages, because they where
only cosmetical nature, didn't fix any bugs and are even with the new
wording in the wiki fine.
For that reason, he is now rejecting my package submissions with
reference to the above changes and some more references to the
wiki, but the other ones have absolute nothing to do with the package.


Why I write this now here? Because Jan did insist on that I move the
discussion to the public mailing list.

   Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Updated rationales for specfile guidelines

Dominique Leuenberger / DimStar
On Mon, 2017-09-04 at 15:44 +0200, Thorsten Kukuk wrote:

> On Sun, Sep 03, Jan Engelhardt wrote:
>
> >
> > Parts of the specfile guidelines have been just amended by me. It
> > might
> > just be considered a redactional (linguistic) edit, but it feels
> > too
> > much on either side of the fence, so here is an explicit
> > notification
> > to those who care.
>
> If somebody wonders about what this is:
> I rejected package changes from Jan to my packages, because they
> where
> only cosmetical nature, didn't fix any bugs and are even with the new
> wording in the wiki fine.
> For that reason, he is now rejecting my package submissions with
> reference to the above changes and some more references to the
> wiki, but the other ones have absolute nothing to do with the
> package.
That sounds like a very strange approach to the things - the guidelines
are 'guidelines' - there are things that are stricter (e.g. share lib
packages must not have non-versioned files) for technical reasons, no
static libs (or if it must be, a static-devel) for security reasons,
patch references in changes for debugging reasons, and then there are
'weaker' ones, that have lower impact. like Wordings of
summaries/description, how many variables I use in a spec file, and so
on.

Changing the wiki to enforce personal style sounds like the wrong
approach

>
> Why I write this now here? Because Jan did insist on that I move the
> discussion to the public mailing list.

Do we have a specific package the review team can look at as a
collective?

Cheers,
Dominique

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updated rationales for specfile guidelines

Johannes Meixner

Hello,

On Sep 6 12:12 Dominique Leuenberger / DimStar wrote (excerpt):
> ... the guidelines are 'guidelines' - there are things that
> are stricter (e.g. share lib packages must not have
> non-versioned files) for technical reasons, no
> static libs (or if it must be, a static-devel)
> for security reasons, patch references in changes
> for debugging reasons, and then there are 'weaker' ones,
> that have lower impact. like Wordings of
> summaries/description, how many variables I use
> in a spec file, and so on.

exactly!

In general guidelines should be written and applied
with a benevolent mindset like:

"Learn the rules so you know how to break them properly."

Enforcing 'weaker' style guidelines is narrow-minded
and - at least from my point of view - it is against
the basic ideas behind freedom as in 'free software'.


Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Updated rationales for specfile guidelines

Simon Lees-3


On 07/09/17 20:01, Johannes Meixner wrote:
>
> Hello,
>
> On Sep 6 12:12 Dominique Leuenberger / DimStar wrote (excerpt):
> Enforcing 'weaker' style guidelines is narrow-minded
> and - at least from my point of view - it is against
> the basic ideas behind freedom as in 'free software'.
>

Almost every open source project i've contributed to has quiet strict
code style guidelines (some even mandate crazy things like 3 spaces for
indentation), how is enforcing guidelines for our spec files any different?

>
> Kind Regards
> Johannes Meixner

--

Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                           Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updated rationales for specfile guidelines

Johannes Meixner

Hello,

On Sep 7 22:18 Simon Lees wrote (excerpt):

> On 07/09/17 20:01, Johannes Meixner wrote:
>>
>> Enforcing 'weaker' style guidelines is narrow-minded
>> and - at least from my point of view - it is against
>> the basic ideas behind freedom as in 'free software'.
>
> Almost every open source project i've contributed to
> has quiet strict code style guidelines (some even
> mandate crazy things like 3 spaces for indentation),
> how is enforcing guidelines for our spec files any different?

There is no difference.
Accordingly almost every open source project is actually
lead by narrow-minded people which is - at least from my
point of view - against the basic ideas behind freedom
as in 'free software'.


Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Updated rationales for specfile guidelines

Michal Kubecek
In reply to this post by Simon Lees-3
On Thursday, 7 September 2017 14:48 Simon Lees wrote:

> On 07/09/17 20:01, Johannes Meixner wrote:
> >
> > On Sep 6 12:12 Dominique Leuenberger / DimStar wrote (excerpt):
> > Enforcing 'weaker' style guidelines is narrow-minded
> > and - at least from my point of view - it is against
> > the basic ideas behind freedom as in 'free software'.
>
> Almost every open source project i've contributed to has quiet strict
> code style guidelines (some even mandate crazy things like 3 spaces
> for indentation), how is enforcing guidelines for our spec files any
> different?

The difference is in the fact that you want to enforce uniformity over
the whole distribution. Let each maintainer choose his style for the
non-essential parts. If there are multiple maintainers, let them unify
on a style. But enforcing even minor details over the whole distribution
would be wrong, I believe.

Michal Kubeček

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Updated rationales for specfile guidelines

Jan Engelhardt-4
In reply to this post by Johannes Meixner

On Thursday 2017-09-07 14:58, Johannes Meixner wrote:
>
> Accordingly almost every open source project is actually
> lead by narrow-minded people which is - at least from my
> point of view - against the basic ideas behind freedom
> as in 'free software'.

Free software, like free speech (FSF mentions both in their definition) does
not mean that anybody is obliged to listen or follow your ideas.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Updated rationales for specfile guidelines

Simon Lees-3
In reply to this post by Johannes Meixner


On 07/09/17 22:28, Johannes Meixner wrote:

>
> Hello,
>
> On Sep 7 22:18 Simon Lees wrote (excerpt):
>> On 07/09/17 20:01, Johannes Meixner wrote:
>>>
>>> Enforcing 'weaker' style guidelines is narrow-minded
>>> and - at least from my point of view - it is against
>>> the basic ideas behind freedom as in 'free software'.
>>
>> Almost every open source project i've contributed to
>> has quiet strict code style guidelines (some even
>> mandate crazy things like 3 spaces for indentation),
>> how is enforcing guidelines for our spec files any different?
>
> There is no difference.
> Accordingly almost every open source project is actually
> lead by narrow-minded people which is - at least from my
> point of view - against the basic ideas behind freedom
> as in 'free software'.
>
>
> Kind Regards
> Johannes Meixner
I prefer to see it as maintainers of 1 Million + LOC open source
projects keeping there code maintainable and easy to work on.

--

Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                           Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updated rationales for specfile guidelines

Johannes Meixner
In reply to this post by Jan Engelhardt-4

On Sep 7 15:13 Jan Engelhardt wrote (excerpt):
> Free software, like free speech (FSF mentions both in their definition) does
> not mean that anybody is obliged to listen or follow your ideas.

Free software, like free speech (FSF mentions both in their definition)
does not mean that anybody is obliged to listen or follow your ideas.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]