Dne 13.3.2013 18:31, James Antill napsal(a):
On Wed, 2013-03-13 at 16:26 +0100, Vít Ondruch wrote:
Dne 13.3.2013 16:18, Toshio Kuratomi napsal(a):
On Wed, Mar 13, 2013 at 01:12:00PM +0100, V?t Ondruch wrote:
If this would be accompanied by the rule, that .spec
files can't be shared as well (using some conditions), this would
allow us to have much faster evolution of our packaging. I'll give
you a few examples.
This is a non-starter, I'm afraid.
Yes, unless you provide any rationale behind your statement, it cannot
start even discussion I am afraid. And since you are just afraid, could
you please share your fears? May be we can overcome them together.
Think of it like having some software that needs to run on FreeBSD and
Linux ... there are differences, but in the vast majority of cases it's
going to be better to have a single source than to fork.
While you could argue that it's "better" to fork more of the time for
spec. file versions, than in C code, I'd rejoin:
1. It being better to share as much code as possible, with conditionals
of the bits you can't share, is accepted wisdom basically everywhere. So
I'd need a great argument/data/etc. to believe this is not true for
spec. files.
Not exactly ... it is definitely fine to have for example one file,
which solves the platform specific bits, included by conditionals then
to have conditionals scattered all around the code. If the code contains
conditional all around, it is unreadable and non-maintainable, hopefully
with exception of original author.
2. The examples I've seen you give to support your case make me think
you need to learn how to write better "portable code" (and weren't
compelling, even though they could be made much better).
3. I didn't see any evaluation on the downsides of forking all the
specfiles (something, again, which history/experience would say is
non-trivial).
4. Even if it's true and it's only good to share the spec files in 10%
of cases, banning the use of something that helps 10% of packages
(~1,000 packages in Fedora) and has no downsides for everyone else is
not something I'd vote for.
"Ban" something is strong word. I would say encourage, e.g. the
guidelines would contain "You *should* not share the .spec, because ..."
...so basically, if you still want to pursue this you'd want to have a
good argument that:
i) Shows how having compatibility is bad for specfiles, in spite of all
historical evidence in related fields.
My initial email in this thread contained examples.
ii) Shows how there is no/little downside to forking specfiles, in
spite of all historical evidence in related fields.
Although the updates in Fedora and EPEL are not prohibited, they are
definitely not encouraged [1]. Basically, you should limit the updates
to bug fixes. If you maintain lively package, there is high chance that
between two releases of Fedora, there was some more significant upstream
release then just bugfixing release. So at this point, the .spec files
between Fedora versions *must* differ. As soon as they differs, it is
good time to give up and update the spec in the master to follow the
recent development in packaging.
If you want share the .spec file, you probably diverge from the
suggestion given you by update policy, that you should not update except
bugfixes, or your package is in clinical death.
Nevertheless, there happens to be mass rebuilds in that case, so your
.spec file in F19 is going to be different although you did not changed
anything in it. So again, what is the point now, since you cannot merge
the branches anymore, with luck, you can cherry-pick the changes and you
have to always fix the changelogs. Or you gave up and for example your
F18 branches now contains the same "mass rebuild" changelog entries?
That seems to be wrong.
iii) Shows that there is actual harm in some packages having
compatibility, even if we'd generally recommend against it after you
proved i) and ii).
...also my personal experience is that directly the opposite of i) and
ii) ... so good luck.
Vít
[1] http://fedoraproject.org/wiki/Updates_Policy#Philosophy
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
