Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora version? 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.
= Tilde versioning
It is available in RPM since 4.10 [1], i.e. Fedora 18. It is prohibited by guidelines [2].
= Support for /usr/lib/rpm/macros.d/
Available since RPM 4.11 [3, 4], i.e. Fedora 19, nobody place the additional macros there (well I'll fix Ruby and RubyGems as soon as I'll have some free cycles). Actually it could be nice scripted.
= Changes in Ruby guidelines
There are currently 3 versions of Ruby guidelines [5], which apply to different versions of Fedora and EPEL anyway.
= %clean section
Not mandated since F13 [6], but widely used in older packages. That could be easily removed by script it there would not be chance that the package is in use for EPEL5
= BuildRoot tag
Not needed since F10! [7] But needed by EPEL. BTW you should not update packages in EPEL, to keep ABI stability, anyway, so why you should carry around such thing in F20? There is high chance that EPEL5 package contains much older version.
= mandatory %defattr at the beginning of %files section
Not needed since RPM 4.4 [8].
This is not exhaustive list. If you just count %clean section, BuildRoot tag and %deffattr, the spec file could be 5 lines shorter. 5 lines which can make difference in maintainability, in attraction new packagers, since they would not need to wonder "what the BuildRoot is there for?"
What I have learned during recent rebuild of Ruby packages is that the .specs, which contains conditions to support different versions of Fedora or EPEL are the one, which are the hardest to maintain. There is no simple way how to automatically migrate them to support newer guidelines. This exactly prohibits the innovation. This prohibits any new feature which we could benefit.
If the .spec would be specific to the Fedora version, it could follow the latest and greatest development. However there are some version specific branches which prevent that.
Some may object, that the resulting binary RPM should be compatible between Fedoras and installable everywhere, but I can assure you, that you cannot install any RPM which depends on Ruby from F18 to F19 and vice versa, so the argument is moot. This apply also to all libraries after soname bump, not just that we are doing something terribly wrong in Ruby.
So please, consider this proposal. In a long term (speaking about really long term now), the .spec file should contain just a few lines, such as SOURCE0 and the rest would be done by a few simple macros. Take a look for example what Java guys did recently [9] and how it used to be [10] (I am sure they could provide you better examples :). This would let us to focus on more important things then copy pasting guidelines to .spec files.
Thank you
Vít
[1] http://www.rpm.org/wiki/Releases/4.10.0 [2] http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Version_Tag [3] http://www.rpm.org/wiki/Releases/4.11.0 [4] https://bugzilla.redhat.com/show_bug.cgi?id=846679 [5] https://fedoraproject.org/wiki/Packaging:Ruby [6] https://fedoraproject.org/wiki/Packaging:Guidelines#.25clean [7] https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag [8] https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions [9] https://fedoraproject.org/wiki/Packaging:Java#Apache_Maven [10] https://fedoraproject.org/w/index.php?title=Packaging:Java&oldid=246507#...
On Wednesday, 13 March 2013 at 13:12, Vít Ondruch wrote:
Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora version? 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.
+1 on versioning guidelines per Fedora version -1 on prohibiting spec file sharing across branches
Regards, Dominik
On Wednesday, 13 March 2013 at 16:12, Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 13 March 2013 at 13:12, Vít Ondruch wrote:
Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora version? 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.
+1 on versioning guidelines per Fedora version -1 on prohibiting spec file sharing across branches
To expand on my -1, your rationale does not explain why we should ban people from conditionalizing certain parts of their spec files to follow guidelines for any Fedora and EPEL version they wish to maintain their packages for. Yes, it adds to maintenance overhead, but the reduced overhead due to having one spec file instead of up to 6[1] balances that. And people are free to use separate, differing specs for each branch already.
[1] rawhide, branched (Fn+1), Fn, Fn-1, EPEL-6, EPEL-5
Regards, Dominik
Dne 13.3.2013 16:35, Dominik 'Rathann' Mierzejewski napsal(a):
On Wednesday, 13 March 2013 at 16:12, Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 13 March 2013 at 13:12, Vít Ondruch wrote:
Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora version? 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.
+1 on versioning guidelines per Fedora version -1 on prohibiting spec file sharing across branches
To expand on my -1, your rationale does not explain why we should ban people from conditionalizing certain parts of their spec files to follow guidelines for any Fedora and EPEL version they wish to maintain their packages for. Yes, it adds to maintenance overhead, but the reduced overhead due to having one spec file instead of up to 6[1] balances that. And people are free to use separate, differing specs for each branch already.
The main reason is that we cannot get rid of legacy stuff from .spec files and start to use new features. The other reason is that it is not possible to reliably script the update process. For example, if you have rubygem and you build it for EPEL and Fedora, you had something like:
%if 0%{fedora} > 0 %global rubyabi 1.9.1 %else %global rubyabi 1.8 %endif
Now we move from %{rubyabi} to ruby(release) and you cannot certainly know that there was such conditionalized definition. So you have to check the .spec manually. You even don't know if that conditions still make sense, if they are in use. They could be even named differently.
That speaks all against sharing.
Vít
On Wed, Mar 13, 2013 at 01:12:00PM +0100, V?t Ondruch wrote:
Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora version?
It is and we already do. For instance, the java guidelines which have differences depending on how the tools in the relevant Fedora release are implemented/available.
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.
-Toshio
Dne 13.3.2013 16:18, Toshio Kuratomi napsal(a):
On Wed, Mar 13, 2013 at 01:12:00PM +0100, V?t Ondruch wrote:
Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora version?
It is and we already do. For instance, the java guidelines which have differences depending on how the tools in the relevant Fedora release are implemented/available.
We should be more specific about that.
For example, it should be clear that if I am packaging new .macros file for F19, it should go into /usr/lib/rpm/macros.d without other conditions. Now, it is small remark squeezed into brackets, which will be skipped when you skim through the guidelines.
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.
Thank you.
Vít
On Wed, Mar 13, 2013 at 04:26:41PM +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:
Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora version?
It is and we already do. For instance, the java guidelines which have differences depending on how the tools in the relevant Fedora release are implemented/available.
We should be more specific about that.
For example, it should be clear that if I am packaging new .macros file for F19, it should go into /usr/lib/rpm/macros.d without other conditions. Now, it is small remark squeezed into brackets, which will be skipped when you skim through the guidelines.
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.
Excellent. /me does his share to prevent flamewars for the day.
Hint: I don't have time for this discussion for the next two weeks, (I'm at a conference), but if you do, you can raise just this aspect on devel list and see what happens.... warning, I expect it to quickly degenerate into a highly unproductive shouting match.
-Toshio
Dne 13.3.2013 16:47, Toshio Kuratomi napsal(a):
On Wed, Mar 13, 2013 at 04:26:41PM +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:
Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora version?
It is and we already do. For instance, the java guidelines which have differences depending on how the tools in the relevant Fedora release are implemented/available.
We should be more specific about that.
For example, it should be clear that if I am packaging new .macros file for F19, it should go into /usr/lib/rpm/macros.d without other conditions. Now, it is small remark squeezed into brackets, which will be skipped when you skim through the guidelines.
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.
Excellent. /me does his share to prevent flamewars for the day.
Hint: I don't have time for this discussion for the next two weeks, (I'm at a conference), but if you do, you can raise just this aspect on devel list and see what happens.... warning, I expect it to quickly degenerate into a highly unproductive shouting match.
This is nothing urgent which would need your immediate attention. If you can find time in two weeks, that's fine with me.
I started here, because I think here is more focused group of people and we can distill some proposal which could make it through review on -devel, FESCo, etc.
<flame> Actually, it is quite normal that governing body comes with rule proposal and people then decide if that is feasible for them. Not sure how it comes that for packaging it should be opposite. </flame>
Thanks
Vít
On Wed, Mar 13, 2013 at 04:57:32PM +0100, V??t Ondruch wrote:
<flame> Actually, it is quite normal that governing body comes with rule proposal and people then decide if that is feasible for them. Not sure how it comes that for packaging it should be opposite. </flame>
Don't have time to participate in long discussion here either but -- FPC's role is 80% judicial and only 20% legislative... ie: we mainly evaluate things that exist to determine whether they make sense for Fedora. The legislative end is mostly where we change an existing guideline (or draft) to make it more sensible for Fedora. Once in a while one of us has the time to dive deeper into making new guidelines from whole cloth but then the rest of the FPC evaluates the new guideline in that same judicial manner.
-Toshio
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.
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.
...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. ii) Shows how there is no/little downside to forking specfiles, in spite of all historical evidence in related fields. 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.
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:
- 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.
- 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).
- I didn't see any evaluation on the downsides of forking all the
specfiles (something, again, which history/experience would say is non-trivial).
- 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
Quoting Toshio Kuratomi (2013-03-13 16:18:15)
On Wed, Mar 13, 2013 at 01:12:00PM +0100, V?t Ondruch wrote:
Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora version?
It is and we already do. For instance, the java guidelines which have differences depending on how the tools in the relevant Fedora release are implemented/available.
Well, you are both partially right I guess :-)
Current Maven guidelines[1] say: "For Fedora 19 and newer, packages SHOULD..."
And then we have section "Older packaging techniques" which says: "From Fedora 15 to Fedora 18, maven 3 is used and the package is called maven-local. Packages built using maven-local ship with pom.xml files. They SHOULD..."
I guess what Vit is asking for is to get some formal/unified way to express these changes between releases. Currently they are expressed ad-hoc *somewhere* in the guideline text. It can be really hard to track down unless:
1) you wrote the guidelines 2) you read whole guidelines 3) both of the above in some cases, because people forget...
What I would propose to Vit: come up with a nice unified way to express these guideline updates. A separate section, tagging, headers...something. I would like to see something unified as well. It's extremely painful to update guidelines in Java and keep same packaging style for all releases. It would be nice if we could break that from time to time...
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.
Well, current F19+ Maven specfiles won't build in F17 and F18. But it's not immediately obvious. It's partially explained in guidelines, but not completely. *If* someone merges spec from rawhide to F17/18 they will be in for weird surprise...
[1] https://fedoraproject.org/wiki/Packaging:Java#Apache_Maven
Dne 13.3.2013 13:12, Vít Ondruch napsal(a):
Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora version? 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.
= Tilde versioning
It is available in RPM since 4.10 [1], i.e. Fedora 18. It is prohibited by guidelines [2].
= Support for /usr/lib/rpm/macros.d/
Available since RPM 4.11 [3, 4], i.e. Fedora 19, nobody place the additional macros there (well I'll fix Ruby and RubyGems as soon as I'll have some free cycles). Actually it could be nice scripted.
= Changes in Ruby guidelines
There are currently 3 versions of Ruby guidelines [5], which apply to different versions of Fedora and EPEL anyway.
= %clean section
Not mandated since F13 [6], but widely used in older packages. That could be easily removed by script it there would not be chance that the package is in use for EPEL5
= BuildRoot tag
Not needed since F10! [7] But needed by EPEL. BTW you should not update packages in EPEL, to keep ABI stability, anyway, so why you should carry around such thing in F20? There is high chance that EPEL5 package contains much older version.
= mandatory %defattr at the beginning of %files section
Not needed since RPM 4.4 [8].
This is not exhaustive list. If you just count %clean section, BuildRoot tag and %deffattr, the spec file could be 5 lines shorter. 5 lines which can make difference in maintainability, in attraction new packagers, since they would not need to wonder "what the BuildRoot is there for?"
What I have learned during recent rebuild of Ruby packages is that the .specs, which contains conditions to support different versions of Fedora or EPEL are the one, which are the hardest to maintain. There is no simple way how to automatically migrate them to support newer guidelines. This exactly prohibits the innovation. This prohibits any new feature which we could benefit.
If the .spec would be specific to the Fedora version, it could follow the latest and greatest development. However there are some version specific branches which prevent that.
Some may object, that the resulting binary RPM should be compatible between Fedoras and installable everywhere, but I can assure you, that you cannot install any RPM which depends on Ruby from F18 to F19 and vice versa, so the argument is moot. This apply also to all libraries after soname bump, not just that we are doing something terribly wrong in Ruby.
So please, consider this proposal. In a long term (speaking about really long term now), the .spec file should contain just a few lines, such as SOURCE0 and the rest would be done by a few simple macros. Take a look for example what Java guys did recently [9] and how it used to be [10] (I am sure they could provide you better examples :). This would let us to focus on more important things then copy pasting guidelines to .spec files.
One more point, there is not visible on the first look what version of Fedora/EPEL the .spec file targets. Shall I do the modifications or not? Although I could do them, I will not, since I am unsure. It needs to check all branches and you still might be wrong what was the intention of maintainer.
Vít
Thank you
Vít
[1] http://www.rpm.org/wiki/Releases/4.10.0 [2] http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Version_Tag [3] http://www.rpm.org/wiki/Releases/4.11.0 [4] https://bugzilla.redhat.com/show_bug.cgi?id=846679 [5] https://fedoraproject.org/wiki/Packaging:Ruby [6] https://fedoraproject.org/wiki/Packaging:Guidelines#.25clean [7] https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag [8] https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions [9] https://fedoraproject.org/wiki/Packaging:Java#Apache_Maven [10] https://fedoraproject.org/w/index.php?title=Packaging:Java&oldid=246507#... -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
On 03/13/2013 04:20 PM, Vít Ondruch wrote:
Dne 13.3.2013 13:12, Vít Ondruch napsal(a):
Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora version? 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.
= Tilde versioning
It is available in RPM since 4.10 [1], i.e. Fedora 18. It is prohibited by guidelines [2].
-1 Any changes to NEVR conventions are dangerous. They need to be supported by all rpm-related tools and all active versions of Fedora.
I.e. I don't see much sense in allowing tilde before all rpm-related tools in Fedora have been tested for supporting this and before all Fedoras' rpms support it (I.e. not before f17 went EOL).
= Support for /usr/lib/rpm/macros.d/
Available since RPM 4.11 [3, 4], i.e. Fedora 19, nobody place the additional macros there (well I'll fix Ruby and RubyGems as soon as I'll have some free cycles). Actually it could be nice scripted.
-1 Too late for f19. Try to propose this as a feature for f20.
= %clean section
Not mandated since F13 [6], but widely used in older packages. That could be easily removed by script it there would not be chance that the package is in use for EPEL5
-1 %clean doesn't do any harm => No need for action. Can be grandfathered.
= BuildRoot tag
Not needed since F10! [7] But needed by EPEL. BTW you should not update packages in EPEL, to keep ABI stability, anyway, so why you should carry around such thing in F20? There is high chance that EPEL5 package contains much older version.
Because specs might be shared?
= mandatory %defattr at the beginning of %files section
Not needed since RPM 4.4 [8].
-1 %clean doesn't harm => No need for action. Can be grandfathered/ignored.
What I have learned during recent rebuild of Ruby packages is that the .specs, which contains conditions to support different versions of Fedora or EPEL are the one, which are the hardest to maintain. There is no simple way how to automatically migrate them to support newer guidelines. This exactly prohibits the innovation. This prohibits any new feature which we could benefit.
If the .spec would be specific to the Fedora version, it could follow the latest and greatest development. However there are some version specific branches which prevent that.
There is no rule prohibiting maintainers from doing so. It's up to a package's maintainer's discretion.
Ralf
Dne 13.3.2013 18:01, Ralf Corsepius napsal(a):
On 03/13/2013 04:20 PM, Vít Ondruch wrote:
Dne 13.3.2013 13:12, Vít Ondruch napsal(a):
Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora version? 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.
= Tilde versioning
It is available in RPM since 4.10 [1], i.e. Fedora 18. It is prohibited by guidelines [2].
-1 Any changes to NEVR conventions are dangerous. They need to be supported by all rpm-related tools and all active versions of Fedora.
Wrong, if the guidelines would be version specific, it would be obvious that you can start using this functionality for F18. Yes, you can hit issues if you try on F17, but it was never intended to work on older releases, so that is not surprise.
I.e. I don't see much sense in allowing tilde before all rpm-related tools in Fedora have been tested for supporting this and before all Fedoras' rpms support it (I.e. not before f17 went EOL).
Yes, testing is definitely needed, but it has nothing to do with f17 EOL.
= Support for /usr/lib/rpm/macros.d/
Available since RPM 4.11 [3, 4], i.e. Fedora 19, nobody place the additional macros there (well I'll fix Ruby and RubyGems as soon as I'll have some free cycles). Actually it could be nice scripted.
-1 Too late for f19.
There is never too late. For Ruby for example, it means to test 3 packages at most. This will make no harm even in the middle of F19 lifecycle.
Try to propose this as a feature for f20.
Actually this is not bad idea, thank you for suggestion.
= %clean section
Not mandated since F13 [6], but widely used in older packages. That could be easily removed by script it there would not be chance that the package is in use for EPEL5
-1 %clean doesn't do any harm
Yes, we both know that, but it does not help anything as well, so why it should be there? It is just bloat.
=> No need for action. Can be grandfathered.
= BuildRoot tag
Not needed since F10! [7] But needed by EPEL. BTW you should not update packages in EPEL, to keep ABI stability, anyway, so why you should carry around such thing in F20? There is high chance that EPEL5 package contains much older version.
Because specs might be shared?
I shown in other thread that the "shared" .spec is not reality. Now even spec for F18 and F19 differs even if you did not touch them, since there was mass rebuild and spec has different revisions and changelog entries.
= mandatory %defattr at the beginning of %files section
Not needed since RPM 4.4 [8].
-1 %clean doesn't harm => No need for action. Can be grandfathered/ignored.
Copy/paste mistake? :) Should I copy/paste my answer as well? ;)
What I have learned during recent rebuild of Ruby packages is that the .specs, which contains conditions to support different versions of Fedora or EPEL are the one, which are the hardest to maintain. There is no simple way how to automatically migrate them to support newer guidelines. This exactly prohibits the innovation. This prohibits any new feature which we could benefit.
If the .spec would be specific to the Fedora version, it could follow the latest and greatest development. However there are some version specific branches which prevent that.
There is no rule prohibiting maintainers from doing so. It's up to a package's maintainer's discretion.
Yes there is no, that is why this thread started. Limited sharing => greater innovation of our packaging => less work for new packages as well as less learning for newcoming packagers, less possibility for error.
Vít
On Thu, 2013-03-14 at 09:46 +0100, Vít Ondruch wrote:
I shown in other thread that the "shared" .spec is not reality. Now even spec for F18 and F19 differs even if you did not touch them, since there was mass rebuild and spec has different revisions and changelog entries.
I respectfully disagree here, shared spec is a reality, lots of packagers use it, I do. And yes, there is one new entry in the changelog of the F19 branch, is it a big deal to merge this change into others? I don't think so. In theory I agree with you, if we really wanted that the changelog reflect the evolution of the spec per branch, but that does mean that I have 5 potentially different spec files to maintain instead of one and then merge the changes back to the other branch.
What I have learned during recent rebuild of Ruby packages is that the .specs, which contains conditions to support different versions of Fedora or EPEL are the one, which are the hardest to maintain. There is no simple way how to automatically migrate them to support newer guidelines. This exactly prohibits the innovation. This prohibits any new feature which we could benefit.
If the .spec would be specific to the Fedora version, it could follow the latest and greatest development. However there are some version specific branches which prevent that.
There is no rule prohibiting maintainers from doing so. It's up to a package's maintainer's discretion.
Yes there is no, that is why this thread started. Limited sharing => greater innovation of our packaging => less work for new packages as well as less learning for newcoming packagers, less possibility for error.
I disagree on the less learning for new packagers, if they package something that they want on the 4/5 branch available, they'll have to go through each version of the guidelines. At the moment we have one set of guidelines which mentions: Note: for EPEL5, you MUST have a %clean section Note: for EPEL5 the %defattr is mandatorry ... If I understand correctly your proposal, to build a package for 4 different branches, I'll have to go through all these branches' guidelines and find out how they different from devel which is the mandatory branch.
In addition, we are a community of volunteer, I think we have to be careful on making their life easier rather than harder and to me, not having the possibility to merge my changes between branches would make my life harder.
My 2cts :)
Pierre
On Thu, 2013-03-14 at 09:57 +0100, Pierre-Yves Chibon wrote:
On Thu, 2013-03-14 at 09:46 +0100, Vít Ondruch wrote:
What I have learned during recent rebuild of Ruby packages is that the .specs, which contains conditions to support different versions of Fedora or EPEL are the one, which are the hardest to maintain. There is no simple way how to automatically migrate them to support newer guidelines. This exactly prohibits the innovation. This prohibits any new feature which we could benefit.
If the .spec would be specific to the Fedora version, it could follow the latest and greatest development. However there are some version specific branches which prevent that.
There is no rule prohibiting maintainers from doing so. It's up to a package's maintainer's discretion.
Yes there is no, that is why this thread started. Limited sharing => greater innovation of our packaging => less work for new packages as well as less learning for newcoming packagers, less possibility for error.
I disagree on the less learning for new packagers, if they package something that they want on the 4/5 branch available, they'll have to go through each version of the guidelines. At the moment we have one set of guidelines which mentions: Note: for EPEL5, you MUST have a %clean section Note: for EPEL5 the %defattr is mandatorry ... If I understand correctly your proposal, to build a package for 4 different branches, I'll have to go through all these branches' guidelines and find out how they different from devel which is the mandatory branch.
One point which I forgot here, there is the question of the review. If we go for different spec for different branches, that means that before starting the review the branches that will be requested should be known and that eventually, the submitter needs to provide multiple spec, one per branch of interest.
Pierre
On Thu, Mar 14, 2013 at 09:57:12AM +0100, Pierre-Yves Chibon wrote:
On Thu, 2013-03-14 at 09:46 +0100, Vít Ondruch wrote:
I shown in other thread that the "shared" .spec is not reality. Now even spec for F18 and F19 differs even if you did not touch them, since there was mass rebuild and spec has different revisions and changelog entries.
I respectfully disagree here, shared spec is a reality, lots of packagers use it, I do.
Yep, we use it extensively for maintaining libvirt related packages and it is incredibly beneficial, reducing the burden of maintaining multiple branches in parallel & which leads to better quality & consistent packages for users.
And yes, there is one new entry in the changelog of the F19 branch, is it a big deal to merge this change into others? I don't think so. In theory I agree with you, if we really wanted that the changelog reflect the evolution of the spec per branch, but that does mean that I have 5 potentially different spec files to maintain instead of one and then merge the changes back to the other branch.
Since the changelog is the last thing in the spec, it is trivial to keep per-branch changelogs while using common data for the rest of the spec.
In any case I consider rpm changelogs to be mostly useless. They are not useful for end users, which is why we provide formal user facing descriptions when submitting updates. They are not useful to packagers since they are just a poor duplicate of GIT history, or the upstream ChangeLog with inaccurate/incomplete info. I rather wish they RPM changelog would just go away, or be auto-filled with GIT history or something else which is more useful
Daniel.
On 03/14/2013 12:20 PM, Daniel P. Berrange wrote:
On Thu, Mar 14, 2013 at 09:57:12AM +0100, Pierre-Yves Chibon wrote:
On Thu, 2013-03-14 at 09:46 +0100, Vít Ondruch wrote:
I shown in other thread that the "shared" .spec is not reality. Now even spec for F18 and F19 differs even if you did not touch them, since there was mass rebuild and spec has different revisions and changelog entries.
I respectfully disagree here, shared spec is a reality, lots of packagers use it, I do.
Yep, we use it extensively for maintaining libvirt related packages and it is incredibly beneficial, reducing the burden of maintaining multiple branches in parallel & which leads to better quality & consistent packages for users.
And yes, there is one new entry in the changelog of the F19 branch, is it a big deal to merge this change into others? I don't think so. In theory I agree with you, if we really wanted that the changelog reflect the evolution of the spec per branch, but that does mean that I have 5 potentially different spec files to maintain instead of one and then merge the changes back to the other branch.
Since the changelog is the last thing in the spec, it is trivial to keep per-branch changelogs while using common data for the rest of the spec.
In any case I consider rpm changelogs to be mostly useless. They are not useful for end users, which is why we provide formal user facing descriptions when submitting updates. They are not useful to packagers since they are just a poor duplicate of GIT history, or the upstream ChangeLog with inaccurate/incomplete info. I rather wish they RPM changelog would just go away, or be auto-filled with GIT history or something else which is more useful
It would be possible to add -f <file> switch to %changelog to read it from external source, which could be generated from git logs or whatever.
OTOH externalizing the changelog is already possible:
%include <changelog-file>
- Panu -
Dne 14.3.2013 11:20, Daniel P. Berrange napsal(a):
In any case I consider rpm changelogs to be mostly useless. They are not useful for end users, which is why we provide formal user facing descriptions when submitting updates. They are not useful to packagers since they are just a poor duplicate of GIT history, or the upstream ChangeLog with inaccurate/incomplete info. I rather wish they RPM changelog would just go away, or be auto-filled with GIT history or something else which is more useful
Although we can agree on that, it is OT for this proposal. Please find older discussion about changelogs, continue there and you'll have my support.
Thank you.
Vít
Dne 14.3.2013 09:57, Pierre-Yves Chibon napsal(a):
On Thu, 2013-03-14 at 09:46 +0100, Vít Ondruch wrote:
I shown in other thread that the "shared" .spec is not reality. Now even spec for F18 and F19 differs even if you did not touch them, since there was mass rebuild and spec has different revisions and changelog entries.
I respectfully disagree here, shared spec is a reality, lots of packagers use it, I do. And yes, there is one new entry in the changelog of the F19 branch, is it a big deal to merge this change into others? I don't think so. In theory I agree with you, if we really wanted that the changelog reflect the evolution of the spec per branch, but that does mean that I have 5 potentially different spec files to maintain instead of one and then merge the changes back to the other branch.
Yes, merge the chances back is wrong. That is the point. Mass rebuild of F19 never happened on F18 branch. Although you make your life easier, the output is definitely incorrect and should not be allowed!
What I have learned during recent rebuild of Ruby packages is that the .specs, which contains conditions to support different versions of Fedora or EPEL are the one, which are the hardest to maintain. There is no simple way how to automatically migrate them to support newer guidelines. This exactly prohibits the innovation. This prohibits any new feature which we could benefit.
If the .spec would be specific to the Fedora version, it could follow the latest and greatest development. However there are some version specific branches which prevent that.
There is no rule prohibiting maintainers from doing so. It's up to a package's maintainer's discretion.
Yes there is no, that is why this thread started. Limited sharing => greater innovation of our packaging => less work for new packages as well as less learning for newcoming packagers, less possibility for error.
I disagree on the less learning for new packagers, if they package something that they want on the 4/5 branch available, they'll have to go through each version of the guidelines. At the moment we have one set of guidelines which mentions: Note: for EPEL5, you MUST have a %clean section Note: for EPEL5 the %defattr is mandatorry ... If I understand correctly your proposal, to build a package for 4 different branches, I'll have to go through all these branches' guidelines and find out how they different from devel which is the mandatory branch.
You have to do it anyway, that is the point. Claiming anything else is not true. If there is inline note about exception, it makes it even harder to notice it. You cannot do diff between two guidelines and really see what is different.
In addition, we are a community of volunteer, I think we have to be careful on making their life easier rather than harder and to me, not having the possibility to merge my changes between branches would make my life harder.
Yes, that is definitely intention to do your life easier and with every release of RPM, your life could be easier if you migrate your spec to the latest greatest features RPM provides, but you don't wan't to. I can't help you with that, sorry
Vít
On Thu, 2013-03-14 at 12:11 +0100, Vít Ondruch wrote:
Dne 14.3.2013 09:57, Pierre-Yves Chibon napsal(a):
What I have learned during recent rebuild of Ruby packages is that the .specs, which contains conditions to support different versions of Fedora or EPEL are the one, which are the hardest to maintain. There is no simple way how to automatically migrate them to support newer guidelines. This exactly prohibits the innovation. This prohibits any new feature which we could benefit.
If the .spec would be specific to the Fedora version, it could follow the latest and greatest development. However there are some version specific branches which prevent that.
There is no rule prohibiting maintainers from doing so. It's up to a package's maintainer's discretion.
Yes there is no, that is why this thread started. Limited sharing => greater innovation of our packaging => less work for new packages as well as less learning for newcoming packagers, less possibility for error.
I disagree on the less learning for new packagers, if they package something that they want on the 4/5 branch available, they'll have to go through each version of the guidelines. At the moment we have one set of guidelines which mentions: Note: for EPEL5, you MUST have a %clean section Note: for EPEL5 the %defattr is mandatorry ... If I understand correctly your proposal, to build a package for 4 different branches, I'll have to go through all these branches' guidelines and find out how they different from devel which is the mandatory branch.
You have to do it anyway, that is the point. Claiming anything else is not true. If there is inline note about exception, it makes it even harder to notice it. You cannot do diff between two guidelines and really see what is different.
At the moment, there is the main guideline to check and they do mention what's specific to EL5/EL6. There are not 5 pages mentioning the guidelines to package for that specific branch.
In addition, we are a community of volunteer, I think we have to be careful on making their life easier rather than harder and to me, not having the possibility to merge my changes between branches would make my life harder.
Yes, that is definitely intention to do your life easier and with every release of RPM, your life could be easier if you migrate your spec to the latest greatest features RPM provides, but you don't wan't to. I can't help you with that, sorry
Well, it might make your life easier for one branch, but not overall. That's at least my opinion/feeling.
Anyway, we have a difference of opinion here. What you find unacceptable I find minor or manageable, you really want different spec per branch, I tend to avoid that as much as I can (even if I agree, there is a point where having different spec makes sense). All I can say is that if you bring this proposal to a wider audience, I'm pretty sure there will be a lot of people feeling the same way.
The current system allows each maintainer to use the latest version of the guidelines or to maintain one spec consistent across branches if he wishes to. I think this is the approach that has the most flexibility and changing it will crease some feathers.
Pierre
Dne 14.3.2013 12:27, Pierre-Yves Chibon napsal(a):
On Thu, 2013-03-14 at 12:11 +0100, Vít Ondruch wrote:
Dne 14.3.2013 09:57, Pierre-Yves Chibon napsal(a):
> What I have learned during recent rebuild of Ruby packages is that the > .specs, which contains conditions to support different versions of > Fedora or EPEL are the one, which are the hardest to maintain. There > is no simple way how to automatically migrate them to support newer > guidelines. This exactly prohibits the innovation. This prohibits any > new feature which we could benefit. > > If the .spec would be specific to the Fedora version, it could follow > the latest and greatest development. However there are some version > specific branches which prevent that.
There is no rule prohibiting maintainers from doing so. It's up to a package's maintainer's discretion.
Yes there is no, that is why this thread started. Limited sharing => greater innovation of our packaging => less work for new packages as well as less learning for newcoming packagers, less possibility for error.
I disagree on the less learning for new packagers, if they package something that they want on the 4/5 branch available, they'll have to go through each version of the guidelines. At the moment we have one set of guidelines which mentions: Note: for EPEL5, you MUST have a %clean section Note: for EPEL5 the %defattr is mandatorry ... If I understand correctly your proposal, to build a package for 4 different branches, I'll have to go through all these branches' guidelines and find out how they different from devel which is the mandatory branch.
You have to do it anyway, that is the point. Claiming anything else is not true. If there is inline note about exception, it makes it even harder to notice it. You cannot do diff between two guidelines and really see what is different.
At the moment, there is the main guideline to check and they do mention what's specific to EL5/EL6. There are not 5 pages mentioning the guidelines to package for that specific branch.
Yes, if you are not speaking about language specific guidelines, where it gets interesting.
In addition, we are a community of volunteer, I think we have to be careful on making their life easier rather than harder and to me, not having the possibility to merge my changes between branches would make my life harder.
Yes, that is definitely intention to do your life easier and with every release of RPM, your life could be easier if you migrate your spec to the latest greatest features RPM provides, but you don't wan't to. I can't help you with that, sorry
Well, it might make your life easier for one branch, but not overall. That's at least my opinion/feeling.
Anyway, we have a difference of opinion here. What you find unacceptable I find minor or manageable, you really want different spec per branch, I tend to avoid that as much as I can (even if I agree, there is a point where having different spec makes sense). All I can say is that if you bring this proposal to a wider audience, I'm pretty sure there will be a lot of people feeling the same way.
It is managable if you care just about your packages. I care about Ruby and hence I care about every other package which depends on Ruby. In such case it is unmanagable.
And we are speaking about possible changes in RPM, that might affect all packages in Fedora.
But since you do various branches in one .spec file, the .spec file becomes un-updatable by script.
The current system allows each maintainer to use the latest version of the guidelines or to maintain one spec consistent across branches if he wishes to. I think this is the approach that has the most flexibility and changing it will crease some feathers.
As well as non-changing it. If beginer takes a look on some hugely conditionalized .spec file, he will screaming escape. .spec file should be sort of configuration file, not a script.
Vít
On Thu, 2013-03-14 at 12:42 +0100, Vít Ondruch wrote:
And we are speaking about possible changes in RPM, that might affect all packages in Fedora.
But since you do various branches in one .spec file, the .spec file becomes un-updatable by script.
Which in some case might not be a bad thing. The other question is, is it really so important to fix all the packages? Or should we just invite the package to clean up the spec when they update their package?
The current system allows each maintainer to use the latest version of the guidelines or to maintain one spec consistent across branches if he wishes to. I think this is the approach that has the most flexibility and changing it will crease some feathers.
As well as non-changing it. If beginer takes a look on some hugely conditionalized .spec file, he will screaming escape. .spec file should be sort of configuration file, not a script.
I agree, like I say, there is a point where having different spec per branch is a good thing (even a necessity), but I think this point should be left to the packager to decide.
Anyway, I think I've expressed what I wanted to say, so I'll try not to run in circles :)
Pierre
Dne 14.3.2013 12:48, Pierre-Yves Chibon napsal(a):
On Thu, 2013-03-14 at 12:42 +0100, Vít Ondruch wrote:
And we are speaking about possible changes in RPM, that might affect all packages in Fedora.
But since you do various branches in one .spec file, the .spec file becomes un-updatable by script.
Which in some case might not be a bad thing. The other question is, is it really so important to fix all the packages? Or should we just invite the package to clean up the spec when they update their package?
Yes, the possibility to be able to modify .spec file by scrip is crucial. Not every change in packaging guidelines is pure aesthatical issue. If you bump ruby(abi) or so, you have to update all packages which depends on it. If you have several ruby(abi)s in several brachnes, then you have no other option then do it manually or keep it broken. Note that there is also plenty of packages which are more or less unmaintained. If I don't do that by script, nobody will do that. Although they are unmaintained, it doesn't mean they could be dropped.
And btw, we got rid of versioned ruby(abi), hopefully forever. There should be no need to script in in future.
The current system allows each maintainer to use the latest version of the guidelines or to maintain one spec consistent across branches if he wishes to. I think this is the approach that has the most flexibility and changing it will crease some feathers.
As well as non-changing it. If beginer takes a look on some hugely conditionalized .spec file, he will screaming escape. .spec file should be sort of configuration file, not a script.
I agree, like I say, there is a point where having different spec per branch is a good thing (even a necessity), but I think this point should be left to the packager to decide.
It would be nice if such .spec files could be automatically recognized at least. Or it it would be somewhere in fedpkg or so.
Anyway, I think I've expressed what I wanted to say, so I'll try not to run in circles :)
Agree
Vít
On 03/14/2013 10:46 AM, Vít Ondruch wrote:
Dne 13.3.2013 18:01, Ralf Corsepius napsal(a):
On 03/13/2013 04:20 PM, Vít Ondruch wrote:
Dne 13.3.2013 13:12, Vít Ondruch napsal(a):
Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora version? 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.
= Tilde versioning
It is available in RPM since 4.10 [1], i.e. Fedora 18. It is prohibited by guidelines [2].
-1 Any changes to NEVR conventions are dangerous. They need to be supported by all rpm-related tools and all active versions of Fedora.
Wrong, if the guidelines would be version specific, it would be obvious that you can start using this functionality for F18. Yes, you can hit issues if you try on F17, but it was never intended to work on older releases, so that is not surprise.
Just FWIW, the tilde support in rpm could trivially be backported to F17. Heck, it's already been backported and included in RHEL-6 (as of 6.4) just to clear the first roadblock from its use in Fedora.
- Panu -
On 03/14/2013 10:09 AM, Panu Matilainen wrote:
On 03/14/2013 10:46 AM, Vít Ondruch wrote:
Dne 13.3.2013 18:01, Ralf Corsepius napsal(a):
On 03/13/2013 04:20 PM, Vít Ondruch wrote:
Dne 13.3.2013 13:12, Vít Ondruch napsal(a):
Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora version? 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.
= Tilde versioning
It is available in RPM since 4.10 [1], i.e. Fedora 18. It is prohibited by guidelines [2].
-1 Any changes to NEVR conventions are dangerous. They need to be supported by all rpm-related tools and all active versions of Fedora.
Wrong, if the guidelines would be version specific, it would be obvious that you can start using this functionality for F18. Yes, you can hit issues if you try on F17, but it was never intended to work on older releases, so that is not surprise.
Just FWIW, the tilde support in rpm could trivially be backported to F17. Heck, it's already been backported and included in RHEL-6 (as of 6.4) just to clear the first roadblock from its use in Fedora.
How about yum, fedpkg, yumex, rpmdev* etc., <insert your custom script here>?
Openly said, I am actually opposed to allowing '~' in rpm at all, because its meaning is non-obvious.
Ralf
On 03/14/2013 11:51 AM, Ralf Corsepius wrote:
On 03/14/2013 10:09 AM, Panu Matilainen wrote:
On 03/14/2013 10:46 AM, Vít Ondruch wrote:
Dne 13.3.2013 18:01, Ralf Corsepius napsal(a):
On 03/13/2013 04:20 PM, Vít Ondruch wrote:
Dne 13.3.2013 13:12, Vít Ondruch napsal(a):
Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora version? 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.
= Tilde versioning
It is available in RPM since 4.10 [1], i.e. Fedora 18. It is prohibited by guidelines [2].
-1 Any changes to NEVR conventions are dangerous. They need to be supported by all rpm-related tools and all active versions of Fedora.
Wrong, if the guidelines would be version specific, it would be obvious that you can start using this functionality for F18. Yes, you can hit issues if you try on F17, but it was never intended to work on older releases, so that is not surprise.
Just FWIW, the tilde support in rpm could trivially be backported to F17. Heck, it's already been backported and included in RHEL-6 (as of 6.4) just to clear the first roadblock from its use in Fedora.
How about yum, fedpkg, yumex, rpmdev* etc., <insert your custom script here>?
As long as they use rpm's version comparison they should be okay. Of course its possible there are wrinkles somewhere, but those are never going to be found unless the stuff is actually tested.
Openly said, I am actually opposed to allowing '~' in rpm at all, because its meaning is non-obvious.
And I'm not going to push for its use in Fedora, I simply wanted to make it technically possible to use it in Fedora. That part is now accomplished, beyond that its up to the community and FPC / FESCo.
- Panu -
Dne 14.3.2013 10:51, Ralf Corsepius napsal(a):
On 03/14/2013 10:09 AM, Panu Matilainen wrote:
On 03/14/2013 10:46 AM, Vít Ondruch wrote:
Dne 13.3.2013 18:01, Ralf Corsepius napsal(a):
On 03/13/2013 04:20 PM, Vít Ondruch wrote:
Dne 13.3.2013 13:12, Vít Ondruch napsal(a):
Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora version? 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.
= Tilde versioning
It is available in RPM since 4.10 [1], i.e. Fedora 18. It is prohibited by guidelines [2].
-1 Any changes to NEVR conventions are dangerous. They need to be supported by all rpm-related tools and all active versions of Fedora.
Wrong, if the guidelines would be version specific, it would be obvious that you can start using this functionality for F18. Yes, you can hit issues if you try on F17, but it was never intended to work on older releases, so that is not surprise.
Just FWIW, the tilde support in rpm could trivially be backported to F17. Heck, it's already been backported and included in RHEL-6 (as of 6.4) just to clear the first roadblock from its use in Fedora.
How about yum, fedpkg, yumex, rpmdev* etc., <insert your custom script here>?
Openly said, I am actually opposed to allowing '~' in rpm at all, because its meaning is non-obvious.
As well as meaning of release, pre-release and epoch ...
Actually every pre-release is using it own way how to handle it. This would finally give it some order.
Vít
Le Mer 13 mars 2013 13:12, Vít Ondruch a écrit :
Hi,
Wouldn't it be possible to have packaging guidelines versioned by Fedora version? 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.
Thank you for the evolution summary, it was very helpful regardless of what is decided here.
Regards,
packaging@lists.fedoraproject.org