This goes out specifically to the Fedora Packaging Committee Members, but is certainly open for comments from all.
We've got a lot of drafts that are queued up for next Tuesday's meeting, so it would be very helpful if you read them all well in advance:
As always, this list is pulled from http://fedoraproject.org/wiki/Packaging/GuidelinesTodo (which embeds the table from http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo ):
ASCII Naming Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming Perl Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/Perl InitDir location (spot) : http://fedoraproject.org/wiki/PackagingDrafts/InitDir Eclipse Plugin Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins OpenOffice.org extensions guidelines (Caolan McNamara) : http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions Secure BuildRoot (Lubomir Kundrak) : http://fedoraproject.org/wiki/PackagingDrafts/SecureBuildRoot Register VirtualProvides (Patrice Dumas) : http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList SysV-style Initscript Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript
I don't have the Java Guidelines draft on the list yet, but I hope that it will be ready by next Tuesday: http://fedoraproject.org/wiki/PackagingDrafts/Java
Next Tuesday will undoubtedly be a longer meeting than normal, so please be prepared.
Thanks,
~spot
Tom spot Callaway (tcallawa@redhat.com) said:
InitDir location (spot) : http://fedoraproject.org/wiki/PackagingDrafts/InitDir
Should this just be merged into the later draft?
SysV-style Initscript Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript
Sooooooooo....
1) I'm of the opinion that LSB headers should be optional. There is no requirement in the LSB for any system scripts to be LSB compliant, and it can cause issues with ordering.
2) Various times it is stated that:
... Note: Fedora's init daemons (sysvinit, upstart) do not currently use non-system boot facilities defined in the <some LSB> line when ordering initscripts. Fedora packagers must ensure that they have priority ordering set correctly in the chkconfig header. ...
This is incorrect. What happens is that on script enablement (chkconfig --add) and script activation/deactivation (chkconfig on/chkconfig off) the LSB dependencies are read, and the start and stop priorities of the scripts are then adjusted to satisfy those dependencies.
What this means:
- dependencies are honored (albeit in a static mechanism) - if you use LSB headers, your start and stop priority may end up being different than what's in the chkconfig: line
This is the same for both upstart (as it is implemented now) and sysvinit.
3) Standardizing on try-restart when we have generally accepted use of 'condrestart' seems problematic.
Bill
On Wed, 2008-03-19 at 22:58 -0400, Bill Nottingham wrote:
Tom spot Callaway (tcallawa@redhat.com) said:
InitDir location (spot) : http://fedoraproject.org/wiki/PackagingDrafts/InitDir
Should this just be merged into the later draft?
Yes, and it is now merged into that draft. :)
- I'm of the opinion that LSB headers should be optional. There is no
requirement in the LSB for any system scripts to be LSB compliant, and it can cause issues with ordering.
Indeed, I agree with this. I've amended the draft to make it very clear that LSB headers are optional.
This is incorrect.
(lots of good text snipped)
Thanks for the correction. I've fixed the mistakes and added a section which is essentially your explanation on how LSB Provides work in Fedora.
- Standardizing on try-restart when we have generally accepted use of
'condrestart' seems problematic.
Agreed. Its now all condrestart.
Thanks for taking the time to review this,
~spot
On Thursday 20 March 2008, Tom "spot" Callaway wrote:
On Wed, 2008-03-19 at 22:58 -0400, Bill Nottingham wrote:
- Standardizing on try-restart when we have generally accepted use of
'condrestart' seems problematic.
Agreed. Its now all condrestart.
-1
Instead, just use try-restart in all examples, and add a note that condrestart should/must for the time being be included in all scripts as an alias to try-restart.
Bill Nottingham wrote:
Tom spot Callaway (tcallawa@redhat.com) said:
InitDir location (spot) : http://fedoraproject.org/wiki/PackagingDrafts/InitDir
Should this just be merged into the later draft?
SysV-style Initscript Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript
"Packages with SysV-style initscripts must put any them into /etc/rc.d/init.d." vs. LSB's standard of /etc/init.d ?
See also recently filed: "packaging policy on init scripts violates LSB standard" http://bugzilla.redhat.com/438357
I personally doubt the pain to properly fix is worth it (flip-flop dir/symlink of /etc/rc.d/init.d /etc/init.d), but I wanted to raise the point for discussion.
-- Rex
On Wed, 2008-03-19 at 18:33 -0400, Tom "spot" Callaway wrote:
This goes out specifically to the Fedora Packaging Committee Members, but is certainly open for comments from all.
We've got a lot of drafts that are queued up for next Tuesday's meeting, so it would be very helpful if you read them all well in advance:
As always, this list is pulled from http://fedoraproject.org/wiki/Packaging/GuidelinesTodo (which embeds the table from http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo ):
ASCII Naming Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
IMO, this proposal is not strict enough.
1. I think, we need to restrict package names to a-z, A-Z, 0-9, -, _
cf.: http://en.opensuse.org/SUSE_Package_Conventions/RPM_Style#1.5._Name_Tag http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Package
2. I do not agree to the "When Upstream Naming is outside ..." section.
This section is unnecessarily/avoidable adding confusion for maintainers. Non-ASCII names have always been banned rsp. technically impossible ever since Linux exists => this is a non-issue.
Perl Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/Perl InitDir location (spot) : http://fedoraproject.org/wiki/PackagingDrafts/InitDir Eclipse Plugin Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins OpenOffice.org extensions guidelines (Caolan McNamara) : http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions Secure BuildRoot (Lubomir Kundrak) : http://fedoraproject.org/wiki/PackagingDrafts/SecureBuildRoot Register VirtualProvides (Patrice Dumas) : http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList SysV-style Initscript Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript
I don't have the Java Guidelines draft on the list yet, but I hope that it will be ready by next Tuesday: http://fedoraproject.org/wiki/PackagingDrafts/Java
Next Tuesday will undoubtedly be a longer meeting than normal, so please be prepared.
Friday, Sunday, Monday are public holidays in Germany (Easter). I'll be off next week (vacation) and therefore will likely not be able to attend due to other commitments.
Ralf
Le jeudi 20 mars 2008 à 04:52 +0100, Ralf Corsepius a écrit :
- I do not agree to the "When Upstream Naming is outside ..." section.
This section is unnecessarily/avoidable adding confusion for maintainers. Non-ASCII names have always been banned rsp. technically impossible ever since Linux exists => this is a non-issue.
That's blatantly false. They've not been "banned", otherwise the document would not be written today, and they've not been "impossible". What changed is that the 8-bits encoding that passed through before are being replaced by an encoding that lifts all the translating/regional incompatibility problems and adds some technical requirements that could be taken care of.
On Thu, 2008-03-20 at 08:31 +0100, Nicolas Mailhot wrote:
Le jeudi 20 mars 2008 à 04:52 +0100, Ralf Corsepius a écrit :
- I do not agree to the "When Upstream Naming is outside ..." section.
This section is unnecessarily/avoidable adding confusion for maintainers. Non-ASCII names have always been banned rsp. technically impossible ever since Linux exists => this is a non-issue.
That's blatantly false.
I guess I don't have to mention that I whole heartily disagree.
They've not been "banned", otherwise the document would not be written today,
This document has been written, because you and your écollier-fonts package submissing are challenging what had been "common sense" to most experienced users, so far.
and they've not been "impossible".
You still seem to refuse to understand the issue.
Installing your package is technically close to impossible to many users, because they are not able to type/read/display its name
May-be you don't see this problem, because "é" is common in your culture - To others, it's unreadable, undisplayable "fly dirt" (German hacker slang for unreadable, undisplayable characters), "Greek" as Englishmen might be calling it.
What changed is that the 8-bits encoding that passed through before are being replaced by an encoding that lifts all the translating/regional incompatibility problems and adds some technical requirements that could be taken care of.
I disagree. SuSE and Debian have it right.
Fedora is once more about to make a (IMNSHO) faulty decision.
Ralf
Le Jeu 20 mars 2008 09:20, Ralf Corsepius a écrit :
On Thu, 2008-03-20 at 08:31 +0100, Nicolas Mailhot wrote:
Le jeudi 20 mars 2008 à 04:52 +0100, Ralf Corsepius a écrit :
- I do not agree to the "When Upstream Naming is outside ..."
section.
This section is unnecessarily/avoidable adding confusion for maintainers. Non-ASCII names have always been banned rsp.
technically
impossible ever since Linux exists => this is a non-issue.
That's blatantly false.
I guess I don't have to mention that I whole heartily disagree.
You can disagree all you want that's a plain fact hard. I did the tests and you didn't. In fact they show a the breakage when it happens is in the upper layers bolted over rpm in the recent years, and I doubt this was a conscious design decision of the people who wrote them.
You could probably shove an 8-bit iso-8859-1 name (which is not the same thing as 7-bit ASCII) through the whole infrastructure today and it wouldn't blink.
They've not been "banned", otherwise the document would not be written today,
This document has been written, because you and your écollier-fonts package submissing are challenging what had been "common sense" to most experienced users, so far.
and they've not been "impossible".
You still seem to refuse to understand the issue.
Installing your package is technically close to impossible to many users, because they are not able to type/read/display its name
Nevertheless the plain fact is that they've not been impossible and they've not been banned before.
May-be you don't see this problem, because "é" is common in your culture - To others, it's unreadable, undisplayable "fly dirt" (German hacker slang for unreadable, undisplayable characters), "Greek" as Englishmen might be calling it.
I perfectly understand the problem, which is why I object to you pretending it's something else to shore up your arguments.
What changed is that the 8-bits encoding that passed through before are being replaced by an encoding that lifts all the translating/regional incompatibility problems and adds some technical requirements that could be taken care of.
I disagree. SuSE and Debian have it right.
Which again are soft policies, not the impossibility you pretend in your message.
On Thu, 2008-03-20 at 18:07 -0500, Jason L Tibbitts III wrote:
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> Fedora is once more about to make a (IMNSHO) faulty decision.
Wow, someone has a device to predict the future.
We are talking about "here and now" - The damage to Fedora allowing utf-8 and chars like $`, etc. in package names does is immediate.
Le vendredi 21 mars 2008 à 04:37 +0100, Ralf Corsepius a écrit :
On Thu, 2008-03-20 at 18:07 -0500, Jason L Tibbitts III wrote:
> "RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> Fedora is once more about to make a (IMNSHO) faulty decision.
Wow, someone has a device to predict the future.
We are talking about "here and now" - The damage to Fedora allowing utf-8 and chars like $`, etc. in package names does is immediate.
Well, you're one of those who raised a stink and now as a result we're likely to get a badly written authoritative guideline that explicitely allows practices much worse than the ones you were complained about (for a package you had no interest in regardless of its naming). Me, I've always been in favour of authorising full utf-8 as soon as our tools were fixed, and let packagers use their best judgement.
But anyway some comments on the proposal:
While Fedora is an international community, for consistency and usability, there needs to be a common character set for package naming.
Neat, however the distribution already has a common character set we enforce everywhere else, that's UTF-8 (even default character set in some package tools like comps files), and this rationalization could apply just as well to UTF-8. Why is it that after weeks of flames we proponents of writing this guideline can not come with a clear rationale?
(note that the first version of the proposal was even worse and called for translating package names in English ; I don't think stuff like libcaca is in any English dictionnary)
Specifically, all Fedora packages must be named using only the 94 printable characters defined by ASCII. These characters are displayed here:
At least the author was careful enough to forbid non-printable characters. But a screenshot is insufficient as definition — a cyrillic A would fit right in.
Fedora packagers are strongly suggested to avoid using non-AlphaNumeric characters from the printable ASCII character set whenever possible, but they are permitted.
Since there is no clear rationale in the spec it's difficult to judge if this kind of clause helps achieving the actual aim. Nevertheless I'll note that: – space is a printable ASCII character and it's not being forbidden in the guideline. Need I point out how completely irrational it is to worry about what packagers might do if allowed UTF-8 and then bless space? – & <> and friends are going to wreak much more havoc than allowing UTF-8 and letting packagers use their good judgement to determine how much UTF-8 is reasonable would ever had – if the rationale was to be mirror, and FTP-safe (one of the arguments advanced on the list) I'll note there are very common limited platforms, and very common storage media, which are unable to handle casing safely, so allowing mixed-case names is dangerous (and if the limited platform is not justifying the guideline I don't see what does)
I'll state it again:
1. If we write a restrictive guideline, at least select correct restrictions.
2. If no one can be bothered writing correct clear restrictions, do not burden packagers with half-baked ones.
3. If we want a permissive guideline, stating that a. package names are UTF-8 encoded like the rest of the distro, b. that packagers should use their good judgement to determine how much UTF-8 is reasonable, c. that infra has the mandate to fix our unicode bugs d. and that it can embargo anything outside the basic latin block till it's done … is just as fine and does not reek of prejudice like this version.
Regards,
Le jeudi 20 mars 2008 à 04:52 +0100, Ralf Corsepius a écrit :
On Wed, 2008-03-19 at 18:33 -0400, Tom "spot" Callaway wrote:
ASCII Naming Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
IMO, this proposal is not strict enough.
- I think, we need to restrict package names to
a-z, A-Z, 0-9, -, _
If FPC goes that way I'll ask for a-z O-9 - only. Casing breaks on Windows mirrors and FAT USB sticks and this kind of incompatibity has been one of the main arguments for writing this guideline. And there's no need for _ when you have - and are asking people to rewrite names anyway.
On Thu, 2008-03-20 at 08:38 +0100, Nicolas Mailhot wrote:
Le jeudi 20 mars 2008 à 04:52 +0100, Ralf Corsepius a écrit :
On Wed, 2008-03-19 at 18:33 -0400, Tom "spot" Callaway wrote:
ASCII Naming Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
IMO, this proposal is not strict enough.
- I think, we need to restrict package names to
a-z, A-Z, 0-9, -, _
Adding '.' (to cater openoffice) would match what had been practice ever since.
If FPC goes that way I'll ask for a-z O-9 - only. Casing breaks on Windows mirrors and FAT USB sticks and this kind of incompatibity has been one of the main arguments for writing this guideline. And there's no need for _ when you have - and are asking people to rewrite names anyway.
Sorry, I can't take this remark serious.
On Thursday 20 March 2008, Ralf Corsepius wrote:
On Wed, 2008-03-19 at 18:33 -0400, Tom "spot" Callaway wrote:
ASCII Naming Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
IMO, this proposal is not strict enough.
- I think, we need to restrict package names to
a-z, A-Z, 0-9, -, _
Seconded, except I think in addition to those listed, "." (eg. openoffice.org) and "+" (eg. gcc-c++) should be fine.
On Sunday 23 March 2008, Ville Skyttä wrote:
On Thursday 20 March 2008, Ralf Corsepius wrote:
On Wed, 2008-03-19 at 18:33 -0400, Tom "spot" Callaway wrote:
ASCII Naming Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
IMO, this proposal is not strict enough.
- I think, we need to restrict package names to
a-z, A-Z, 0-9, -, _
Seconded, except I think in addition to those listed, "." (eg. openoffice.org) and "+" (eg. gcc-c++) should be fine.
Forgot to note that for the record, like I've always been, I'd still be all for going all lowercase, but I fear trying to push this could create a fuss which would endanger passing of the whole draft.
Le dimanche 23 mars 2008 à 17:48 +0200, Ville Skyttä a écrit :
Forgot to note that for the record, like I've always been, I'd still be all for going all lowercase, but I fear trying to push this could create a fuss which would endanger passing of the whole draft.
So you advocate bowing to a group of people that raised a fuss, and not doing what you think is the right thing because others people may raise a fuss? Where is the engineering in that? Or should we dispense with the whole FPC thing and just do online polls?
On Sunday 23 March 2008, Nicolas Mailhot wrote:
Le dimanche 23 mars 2008 à 17:48 +0200, Ville Skyttä a écrit :
Forgot to note that for the record, like I've always been, I'd still be all for going all lowercase, but I fear trying to push this could create a fuss which would endanger passing of the whole draft.
So you advocate bowing to a group of people that raised a fuss,
Personally, I'm surprised that the the thing in question is something that even needs much discussion, and further I don't think people advocating sticking with a subset of ASCII are necessarily the fussier side in this debate.
and not doing what you think is the right thing because others people may raise a fuss? Where is the engineering in that?
It's called incremental engineering. I'd rather get a subset of possible improvements in smaller digestible chunks than none at all.
Or should we dispense with the whole FPC thing and just do online polls?
I believe that way we'd get more folks' opinions voiced and counted which is good, but would also practically be left without the work the FPC does when working with drafts after they're submitted and before they're voted on which is a bigger drawback than using polls would be good for.
On Wed, 2008-03-19 at 18:33 -0400, Tom "spot" Callaway wrote:
This goes out specifically to the Fedora Packaging Committee Members, but is certainly open for comments from all.
We've got a lot of drafts that are queued up for next Tuesday's meeting, so it would be very helpful if you read them all well in advance:
Due to the fact, I'll likely not be able to attend on Tuesday, preliminary comments/answers/votes interspersed.
ASCII Naming Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
Already replied in a separate mail.
Perl Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/Perl
Generally OK, but I am missing a section on perl subdirectory directory ownership.
My vote: 0 without such a section, +1 with such a section.
Also, I do not agree upon the section on "Makefile.PL vs. Build.PL", but ... this is nothing new. I would prefer leaving the choice to the maintainer and not to explicitly recommend Build.PL.
InitDir location (spot) : http://fedoraproject.org/wiki/PackagingDrafts/InitDir
0, I don't understand what this draft is trying to say and which problems it is trying to solve. Could you explain?
Eclipse Plugin Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins
0, no opinion on this.
OpenOffice.org extensions guidelines (Caolan McNamara) : http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions
OK for FC > 9, not OK for FC < 9
The unopkg concerns still apply - /usr/bin/unopkg is not available for FC < 9 Updating the FC8/7 packages to provide them won't help, because users might not have "updates" installed.
- Also, I am not sure if /usr/bin is the appropriate location to install unopkg. /usr/sbin/ might be more appropriate.
Secure BuildRoot (Lubomir Kundrak) : http://fedoraproject.org/wiki/PackagingDrafts/SecureBuildRoot
+1.
OK as a recommendation for Fedora < 10, but should not be made mandatory before Fedora 10 (or even later), IMO.
Should this proposal be accepted, rel-eng should implement it into all packages during a mass-rebuild, may-be accompanied with rpm's upstream implementing it as "default buildroot" into (FC10's) rpm.
Register VirtualProvides (Patrice Dumas) : http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
-1
Not clear enough. Many packages apply virtual provides not covered by these lists (e.g. alternate package names, obsoletes/provides, legacy provides etc.) This proposal doesn't specify which class of virtual provides it is aiming at.
SysV-style Initscript Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript
+1, Seems OK to me.
I don't have the Java Guidelines draft on the list yet, but I hope that it will be ready by next Tuesday: http://fedoraproject.org/wiki/PackagingDrafts/Java
0, for now, no opinion on that. I don't see any obvious mistake/flaw, but I am not sufficiently knowledgeable on java to be able to comment on details.
Ralf
On Thu, Mar 20, 2008 at 06:22:39AM +0100, Ralf Corsepius wrote:
Register VirtualProvides (Patrice Dumas) : http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
-1
Not clear enough. Many packages apply virtual provides not covered by these lists (e.g. alternate package names, obsoletes/provides, legacy provides etc.) This proposal doesn't specify which class of virtual provides it is aiming at.
Thanks for the input, I completly forgot about those since they are outside of the scope, though alternate names is at the limit... I am indeed focused on alternate functionalities or similar provides. I'll update.
-- Pat
On Thu, 2008-03-20 at 06:22 +0100, Ralf Corsepius wrote:
Perl Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/Perl
Generally OK, but I am missing a section on perl subdirectory directory ownership.
My vote: 0 without such a section, +1 with such a section.
I've added a section to the draft that reflects what the general guidelines already have. Please let me know if you feel this is sufficient.
InitDir location (spot) : http://fedoraproject.org/wiki/PackagingDrafts/InitDir
0, I don't understand what this draft is trying to say and which problems it is trying to solve. Could you explain?
This draft has been absorbed into a section in the SysVInitScript draft. I've also tried to make it more clear.
OpenOffice.org extensions guidelines (Caolan McNamara) : http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions
OK for FC > 9, not OK for FC < 9
The unopkg concerns still apply
- /usr/bin/unopkg is not available for FC < 9
Updating the FC8/7 packages to provide them won't help, because users might not have "updates" installed.
The guidelines could always add a Require for the specific update n-v-r to ensure that users do have the updates installed.
Secure BuildRoot (Lubomir Kundrak) : http://fedoraproject.org/wiki/PackagingDrafts/SecureBuildRoot
+1.
OK as a recommendation for Fedora < 10, but should not be made mandatory before Fedora 10 (or even later), IMO.
This draft is specifically targeted for F10 and later. There is no intention to do mass rebuilds to enforce this in F9 or older.
~spot
On Thursday 20 March 2008, Tom "spot" Callaway wrote:
Perl Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/Perl
1) cpanspec should be pushed further down in the draft.
2) Versioned MODULE_COMPAT_ Requires: "This is to ensure that all perl modules are built against the appropriate version of perl."
This rationale is wrong - it doesn't ensure that, but that packages have a dependency to a perl that uses stuff from dirs versioned with that version number.
3) ExtUtils::Build doesn't exist AFAIK, did you mean Module::Build?
Eclipse Plugin Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins OpenOffice.org extensions guidelines (Caolan McNamara) : http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions
These look mostly sane, will need to read them some more though.
Secure BuildRoot (Lubomir Kundrak) : http://fedoraproject.org/wiki/PackagingDrafts/SecureBuildRoot
-1 to any buildroot suggestion that doesn't propose implementing it internally in rpm aiming for eventual deprecation and elimination of the BuildRoot tag (and related "rm -rf"'s) in specfiles.
Anyway, specific to the submitted draft, both alternatives cause buildroot trashing even with innocent "rpm -q --specfile foo.spec" or "rpmbuild -bp foo.spec" or "rpmbuild -bs foo.spec".
Additionally, the second makes dangerous assumptions which can wreak havoc in %clean when one overrides the build root (eg. %buildroot in ~/.rpmmacros).
Register VirtualProvides (Patrice Dumas) : http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
+1 to the general idea, however I'm somewhat uncertain about server(port_name), it needs more explanation. Consider for example the tomcat5 package: it's configured to use port 8080 by default. I don't think server(webcache) would describe it well at all. Also, changing servers to run in non-default ports is pretty common and kind of breaks the "contract" of server(port_name), but perhaps that's just a documentation issue.
On Sun, Mar 23, 2008 at 06:22:47PM +0200, Ville Skyttä wrote:
Register VirtualProvides (Patrice Dumas) : http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
+1 to the general idea, however I'm somewhat uncertain about server(port_name), it needs more explanation. Consider for example the
You mean on http://fedoraproject.org/wiki/VilleSkytt%C3%A4/VirtualProvides
There is no mention of server(port_name) on http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
It is explained on http://fedoraproject.org/wiki/PackagingDrafts/ServerProvides I had understood that it had been ratified, but I may be wrong. I wanted to wait for the guideline to have find a new home with a more definitive content, but I can add the link right now on http://fedoraproject.org/wiki/VilleSkytt%C3%A4/VirtualProvides
tomcat5 package: it's configured to use port 8080 by default. I don't think server(webcache) would describe it well at all. Also, changing servers to
8080 is used for too much stuff to be usefull in a Requires, in my opinion. Still should be server(webcache) is a server listening on localhost on this port wants to have this ability provided, in case it would have make sense.
run in non-default ports is pretty common and kind of breaks the "contract" of server(port_name), but perhaps that's just a documentation issue.
Also the server may not be started.
-- Pat
On Sunday, 23 March 2008 at 21:01, Patrice Dumas wrote:
On Sun, Mar 23, 2008 at 06:22:47PM +0200, Ville Skyttä wrote:
[...]
tomcat5 package: it's configured to use port 8080 by default. I don't think server(webcache) would describe it well at all. Also, changing servers to
8080 is used for too much stuff to be usefull in a Requires, in my opinion. Still should be server(webcache) is a server listening on localhost on this port wants to have this ability provided, in case it would have make sense.
Instead of "server listening on port foo", we should think of these as "server which provides foo".
run in non-default ports is pretty common and kind of breaks the "contract" of server(port_name), but perhaps that's just a documentation issue.
Also the server may not be started.
Precisely.
Regards, R.
On Tue, Mar 25, 2008 at 01:34:59PM +0100, Dominik 'Rathann' Mierzejewski wrote:
Instead of "server listening on port foo", we should think of these as "server which provides foo".
Indeed, but then this would be a completly different meaning. It is actually what webserver is since it it used for an http server with cgi handling.
-- Pat
"VS" == Ville Skyttä ville.skytta@iki.fi writes:
VS> -1 to any buildroot suggestion that doesn't propose implementing VS> it internally in rpm aiming for eventual deprecation and VS> elimination of the BuildRoot tag (and related "rm -rf"'s) in VS> specfiles.
I have to agree. We've been through this once already (painfully, at that) and I don't really see the point of doing it again unless we make real progress in getting this buildroot nonsense out of the specfiles and into rpm.
One issue with the security argument made in the proposal is that, while a laudable goal, the actual exposure isn't due to the buildroot specification in Fedora packages, since we could fix all of those and there would still be exposure when someone rebuilds packages that don't come from Fedora. The exposure is in the rpmbuild infrastructure itself, and honestly I think that it would be more productive if the security arguments were directed there.
- J<
On Wednesday, 19 March 2008 at 23:33, Tom spot Callaway wrote:
This goes out specifically to the Fedora Packaging Committee Members, but is certainly open for comments from all.
We've got a lot of drafts that are queued up for next Tuesday's meeting, so it would be very helpful if you read them all well in advance:
As always, this list is pulled from http://fedoraproject.org/wiki/Packaging/GuidelinesTodo (which embeds the table from http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo ):
ASCII Naming Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming Perl Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/Perl
Both look fine.
Eclipse Plugin Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins
The build commands (java calls) look horribly complicated. I'm quite convinced these should be made into rpm macros.
OpenOffice.org extensions guidelines (Caolan McNamara) : http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions
Looks fine.
Secure BuildRoot (Lubomir Kundrak) : http://fedoraproject.org/wiki/PackagingDrafts/SecureBuildRoot
As discussed in this thread, I think this should be embedded into %install and %clean and the Buildroot: tag should just go away.
Register VirtualProvides (Patrice Dumas) : http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
OK.
SysV-style Initscript Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript
Complicated, but I guess OK.
I don't have the Java Guidelines draft on the list yet, but I hope that it will be ready by next Tuesday: http://fedoraproject.org/wiki/PackagingDrafts/Java
Not ready, I guess?
Next Tuesday will undoubtedly be a longer meeting than normal, so please be prepared.
I can't promise anything, but I might be able to whip up some patches for those macros I mentioned above in a few days.
Regards, R.
Hi All,
I've been reading most guidelines proposed for discussion today, and I would like all the other FPC members todo the same, we have a lot of guidelines to discuss tonight, if we all have already read them we can hopefully get through them all quickly.
Regards,
Hans
Le Mar 25 mars 2008 13:27, Dominik 'Rathann' Mierzejewski a écrit :
Eclipse Plugin Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins
The build commands (java calls) look horribly complicated. I'm quite convinced these should be made into rpm macros.
Or better (IMHO) consolidated in a script package that Eclipse Plugins BR.
RPM macros are hell to version and update, and I'm 150% sure the Eclipse Plugin build process is going to change in the next version.
On Tuesday, 25 March 2008 at 17:02, Nicolas Mailhot wrote:
Le Mar 25 mars 2008 13:27, Dominik 'Rathann' Mierzejewski a écrit :
Eclipse Plugin Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins
The build commands (java calls) look horribly complicated. I'm quite convinced these should be made into rpm macros.
Or better (IMHO) consolidated in a script package that Eclipse Plugins BR.
Fine by me.
RPM macros are hell to version and update, and I'm 150% sure the Eclipse Plugin build process is going to change in the next version.
Good reason not to put it in rpm-build then.
Regards, R.
Tom "spot" Callaway wrote:
This goes out specifically to the Fedora Packaging Committee Members, but is certainly open for comments from all.
We've got a lot of drafts that are queued up for next Tuesday's meeting, so it would be very helpful if you read them all well in advance:
As always, this list is pulled from http://fedoraproject.org/wiki/Packaging/GuidelinesTodo (which embeds the table from http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo ):
ASCII Naming Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
Were you going to add something about working with other distros if transliteration is not done upstream? (Jesse's post: https://www.redhat.com/archives/fedora-packaging/2008-March/msg00169.html )
Perl Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/Perl
Looks sane
Eclipse Plugin Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins
Do we want the Group tag information? I know we've decided group is irrelevant in the main guidelines.
In the Jar Expansion (rare) item: - I'd remove (rare) from the title. - Should we remove the debug_package %{nil} workaround since there's another workaround listed and we want debug packages?
OpenOffice.org extensions guidelines (Caolan McNamara) : http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions
For item #3, does it matter which of the three directory names is used? Should we pick one?
I'd split item #5 into two as the first sentence deals with package naming and the second with directory locations.
#5b -- In the second part of 5, I'd list both the arch directory and arch-independent directory and I'd list them with macros: {_datadir}/package-name & %{_libdir}/package-name
#5b -- Should we have plugins install into subdirectories owned by openoffice.org-core? ie: %{_libdir}openoffice.org and %{_datadir}/openoffice.org. Note that %{_datadir}/openoffice.org doesn't currently exist, so it's a new directory that openoffice.org-core would need to provide.
Structure: I'd reorder the items so they match the order in which one encounters them in the spec file: 5a 6 4 2 3 7 5b 3 1
Having short titles instead of just numbers might also be good.
Secure BuildRoot (Lubomir Kundrak) : http://fedoraproject.org/wiki/PackagingDrafts/SecureBuildRoot
Panu, can buildroot go into rpmbuild?
Register VirtualProvides (Patrice Dumas) : http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
I'd rather the page listed what should be added as the primary point of reference. That will also justify its existence. For instance, if the purpose is collaboration between packages, why list internal provides?
What makes the example of kuipc/cernlib(devel) internal? It is for one package to require another so I don't understand the distinction.
SysV-style Initscript Guidelines (spot) : http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript
rh_status in example superfluous?
lsb header-- how actually works would be better in a noteclass (but that might not support formatting)
lsb header example first instead of summary?
Trim this from ScripletSnippets? http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-1fc158879abd9...
I don't have the Java Guidelines draft on the list yet, but I hope that it will be ready by next Tuesday: http://fedoraproject.org/wiki/PackagingDrafts/Java
I still see open questions here.
-Toshio
packaging@lists.fedoraproject.org
-
Bill Nottingham -
Dominik 'Rathann' Mierzejewski -
Hans de Goede -
Jason L Tibbitts III -
Nicolas Mailhot -
Patrice Dumas -
Ralf Corsepius -
Rex Dieter -
Tom Callaway -
Toshio Kuratomi -
Ville Skyttä