You are not logged in.
Pages: 1
I open this thread in reply to devs that go OT in other threads ( Common PKGBUILD mistakes & Improving Namcap ). I don't quote anything, we know what we have written.
The order of field is important. Why?
Because you, dear devs, don't check the AUR PKGBUILD ( It isn't in your duties.. I know ). It is our ( of TUs ) daily work; and you can't imagine how many revolting PKGBUILD... Without any sense. And a mandatory order would make our work more, and more easy than now. ganja_guru mean this, in his post on TU-mailing list:
http://www.archlinux.org/pipermail/tur- … 04164.html
His word:
For the official repo's, we like to keep the arch=() tag in a standard
location in the PKGBUILD's
What does it mine?
That we have a standard, and this standard is PKGBUILD.proto, located in /var/abs, which is written by devs. And now you won't respect what you write?
Finally, confusion is the same of semplicity? IMHO, it isn't.
If yes for you, please, don't mark me as a stupid, when I try ( in respect of packaging standard, that says what quoted below ) to simplify our work.
Try to preserve the order of the PKGBUILD as shown above. arch=() should come after pkgdesc="". license=() should come after url=""
http://wiki.archlinux.org/index.php/Arc … _Standards
Thanks to all, and excuse me for my poor english ( when I'm angry I can't use the right word on the right place ).
Last thing: I hope that some devs don't put their package under AUR, because I ( and, IMHO, all TUs ) can't mark their PKGBUILD as safe
Bye all
Offline
Try to preserve the order of the PKGBUILD as shown above. arch=() should come after pkgdesc="". license=() should come after url=""
Please note that it was Tardo, a TU, that added that section to the wiki page, not a dev.
I also don't see how it was OT - one thread was discussing how checking ordering of variables could improve namcap, and the other thread discussed how ordering of variables was a mistake in PKGBUILDs - in either case, ordering of variables in a PKGBUILD was on-topic. However, consolidating those discussions into one thread certainly makes sense, since it's the same discussion in two places.
Now, I agree that order of the fields in a PKGBUILD is important for clarity and readability, however I don't think it needs to be enforced as a show-stopper. A polite "please rearrange your fields to improve readability and make our jobs easier" note would be fine, but I really don't think it's worth keeping a pkg flagged as unsafe over something like that.
And for the record, I was a TU before I was a dev. I know what running through packages and flagging them is like. I still stand by my opinion.
Offline
I was going to leave this alone, but for the sake of accuracy, I'll add the following.
PKGBUILD.proto is not a standard, it is a sample PKGBUILD. There is no requirement for the fields to be in any particular order, and there never will be. ganja_guru's mail linked above is his own decision, not an Arch policy - as you noted, the PKGBUILDs for official packages do not follow any particular field order.
Imposing a spurious "standard" on AUR users simply to make your job as a TU easier is wrong IMO - and like Cerebral, I was also a TU before I was a dev.
And finally, I will be reviewing tardo's addition to the Packaging Standards as it relates to this subject.
Offline
Maybe we ought to consider removing packaging standards from the wiki/locking them down. I don't like that anyone can change them, in what should be a defined standard.
Regardless, defining order is redundant. It's common sense and convention to have name and version at the top.
James
Offline
Imposing a spurious "standard" on AUR users simply to make your job as a TU easier is wrong IMO - and like Cerebral, I was also a TU before I was a dev.
I completely agree. I think tom's re-wording is more than adequate.
Maybe we ought to consider removing packaging standards from the wiki/locking them down. I don't like that anyone can change them, in what should be a defined standard.
I think that is a good idea too.
Offline
So, order isn't mandatory, right?
But is important for readability and clarity...
and a patch that show a WARNING ( not an error ) about order of field, in namcap ( and not in makepkg, there is a difference ) is stupid? Clarity is fundamental part of KISS philosophy, keep it in mind: and a control tool must be precise. If someone is lazy, simply don't need to use this control tool, and build directly with makepkg.
Other question: For me, the order of field isn't important when I flag a package safe ( you have misunderstood me ). Simply, I see many PKGBUILD ( some in official repo ) with a personal variables without _ and other errors... I mean this when I'm talking about flagging safe.
Last thing: Locking the packaging standards page would be a good idea.
Offline
So, order isn't mandatory, right?
No, it never was.
But is important for readability and clarity...
As long as the first 4 vars were pkgname, pkgver, pkgrel and pkgdesc and source, md5sumes came last it never bothered me as a TU.
and a patch that show a WARNING ( not an error ) about order of field, in namcap ( and not in makepkg, there is a difference ) is stupid?
Just unnecessary
Clarity is fundamental part of KISS philosophy, keep it in mind: and a control tool must be precise. If someone is lazy, simply don't need to use this control tool, and build directly with makepkg.
We can't make people use namcap, just as much as we can't make them follow the standards. Anyway, order never was mandatory.
Other question: For me, the order of field isn't important when I flag a package safe ( you have misunderstood me ). Simply, I see many PKGBUILD ( some in official repo ) with a personal variables without _ and other errors... I mean this when I'm talking about flagging safe.
This is whole different matter in my opinion. Not using the _ for custom variables would be breaking "our" own rules
Offline
Pages: 1