PKGBUILD advice

STiAT · 2007-07-17 10:29:28

Hello Tardo,

Just step trough the community repo, and tell me if you would flag the packages safe. I stepped trough the (whole) repo, and i wouldn't.

So i think we should start at our own doors, making our pkgbuilds to stardards. Often, unofficial patches are used, the order isn't correct (i don't know if my order is right in all pkgbuilds), sometimes namcap wasn't used etc. etc.

Our pkgbuilds are the ones the users should be referred to.

Yours,
STi

wizzomafizzo · 2007-07-17 12:18:06

I still don't agree with the cosmetic rules. Mistake 1, 2, 5, 7 and 10 are all purely cosmetic details in PKGBUILDs, there's no point in enforcing them as law. In fact the only one I agree with is number 7, empty variables really are silly. The one part I *really* don't agree with is the order of variables, why should this matter? It's stupid for people to chuck a hissy fit over this, who cares. That said I really don't want namcap complaining to me about something as trivial as text ordering.

Half of these mistakes still stand and are very important, but I don't think how a PKGBUILD looks should ever become a factor to whether it's marked safe or not.

dtw · 2007-07-17 12:32:37

I agree - the order of the arch= and license= variables and the position of the md5sum array are of little concern. I don't quite see why someone should take it upon themself to start barking at people about it.

Having said that, I do think the TUs have the right to arbitrate over what they will and won't mark safe but reinterpreting the pkging standards to this degree is a little OTT, not to mention pedantic.

Last edited by dtw (2007-07-17 13:01:37)

Cerebral · 2007-07-17 13:23:39

About the cosmetic points - you'd be surprised how much readability is improved if they all follow the same order. As far as bash is concerned, yes, order doesn't matter, but one of the nice things about PKGBUILDs is they're generally very easy for a regular user to read; IMO any step toward making them more readable is a good step.

wizzomafizzo · 2007-07-17 13:29:11

I should probably clarify, I don't mean PKGBUILDs should be in any order someone feels like at the time. I mean the readability/cosmetic details should not be the difference between a persons PKGBUILD being marked safe or not. Readability is all well and good but I think a line needs to be drawn when it's implied your PKGBUILDs aren't going to be marked safe and the tools I use to check them are going to tell me about such details.

Cerebral · 2007-07-17 14:17:27

wizzomafizzo wrote:

I should probably clarify, I don't mean PKGBUILDs should be in any order someone feels like at the time. I mean the readability/cosmetic details should not be the difference between a persons PKGBUILD being marked safe or not. Readability is all well and good but I think a line needs to be drawn when it's implied your PKGBUILDs aren't going to be marked safe and the tools I use to check them are going to tell me about such details.

Hm, I suppose I have to agree that having order of variables be a halting "problem" is getting a bit anal.

dolby · 2007-07-17 15:41:35

maybe there should be a PKGBUILD.proto link in the AUR homepage so that ppl can grab this to use. not all ppl use ABS..

Last edited by dolby (2007-07-17 15:42:12)

nesl247 · 2007-07-17 17:18:23

I guess I'm going to have to agree with tardo here, but I think even what he says is a bit lax. I'd personally prefer it if we had the variables grouped.

So that all the depends must come after the pkg info, or this after that, etc. I'd just thinking giving a blank line after every group (such as depends/conflicts/replaces, pkginfo, etc) would make it even more readable.

And the reason I agree that we should have the requirement, is because it means that the authors have to pay attention to what they are doing. And doing so, will have a better chance of them creating a better pkgbuild by actually taking the time to look it over.

I know a lot of you are going to disagree, but this is just my take on it.

dtw · 2007-07-17 17:31:04

What are we really talking about here? Trying to reduce the number of really poorly laid out and unreadable PKGBUILDs or making everyone conform to exactly one way of doing things? It seems like the latter but maybe the intention is the former. If the former is the priority then I say that no amount of docs or fancy tools will ever overcome willful ignorance and therefore "legislating" these things is just a burden on the rest of us.

If it's the latter than I'll toe the same line as many of the other devs: I got better things to do ;-)

nesl247 · 2007-07-17 17:40:48

Well, could be done is not make it a requirement, but no pkgbuild will move to community unless it follows the guidelines. Thus pkgbuilds can be marked safe, but not make it into community until the original author, or the person taking it over conforms to the guidelines..

And I'm saying this because guidelines are just that, help, hints, etc. Not rules.

Last edited by nesl247 (2007-07-17 17:44:39)

ezzetabi · 2007-07-17 17:49:03

Question
if the free order bothers you so much, why not just change makepkg so it accepts only packages where order is correct?

tardo · 2007-07-18 05:06:57

sorry guys, was away on a short vacation.... I'll try and keep my answers brief.

What are we really talking about here? Trying to reduce the number of really poorly laid out and unreadable PKGBUILDs or making everyone conform to exactly one way of doing things?

My intention is the former. I for one have no intention of policing every PKGBUILD in the AUR.

maybe there should be a PKGBUILD.proto link in the AUR homepage so that ppl can grab this to use. not all ppl use ABS..

There's a big link that says "ArchLinux Packaging Standards" which points straight to the wiki. An PKGBUILD.proto is there.

but one of the nice things about PKGBUILDs is they're generally very easy for a regular user to read; IMO any step toward making them more readable is a good step.

This here is my intention. I actually find it easier to read 100 neat PKGBUILDs than 10 untidy ones.

I mean the readability/cosmetic details should not be the difference between a persons PKGBUILD being marked safe or not

This isn't my intention. If someone's PKGBUILD is done well, but not necessarily in order, I mark it safe. If stuff like the license field is a string, etc, it gets annoying to leave the same comment on every PKGBUILD.

So i think we should start at our own doors, making our pkgbuilds to stardards. Often, unofficial patches are used, the order isn't correct (i don't know if my order is right in all pkgbuilds), sometimes namcap wasn't used etc. etc.

I work strictly in CURRENT-64, so please "cvs up". Every PKGBUILD i've gone through, I've patched up. Also, I'm not against unofficial patches as I look at the patches to be sure they don't do anything unintended.

It should take very little effort to fix these mistakes, and I'd really like to reach the 2500 milestone, so help us out people.

Please don't misunderstand me. I'm not trying to set up rules, neither am I trying to enforce a standard. I just WANT a standard. This is about the same as any code hacking standard (tabs for indentations, {} on different lines, comments with /* */, etc.). You're not obligated to follow any of these rules, you just make my job a lot easier by doing so.

dtw · 2007-07-18 08:46:46

tardo wrote:

What are we really talking about here? Trying to reduce the number of really poorly laid out and unreadable PKGBUILDs or making everyone conform to exactly one way of doing things?
My intention is the former. I for one have no intention of policing every PKGBUILD in the AUR.

dtw wrote:

no amount of docs or fancy tools will ever overcome willful ignorance

It's a losing battle. Making guidelines more stringent will only adversely affect those that follow them already, it's not going to improve the pkging of people that don't follow them is it? I do feel your pain though.

iphitus · 2007-07-18 09:00:32

Packaging standards are governed by the developers, in particular, the pacman developers. Trusted users are tasked with enforcing these, within their own packages, and the AUR. This does not include adding to, or enhancing them.

If you wish to adjust the packaging standards, please file a feature request on flyspray. We do not need people parroting unofficial standards, compatible or not.

If you wish to offer "advice" please mark it as so. Stating that these are "mistakes" implies that they violate the standard, which for some of the suggestions, in particular order -- is not the case. Order of variables is a convention - it's common sense to put pkgname+pkgver at the top - defining it is redundant.

man PKGBUILD

For future reference, the PKGBUILD man page should be considered the standard, as it comes from the developers. The wiki, being a publicly editable page, thus having no permanence, is not. As with any document, the man page may have errors, in which case a bug should again be filed.

James

tardo · 2007-07-18 15:09:00

Renamed the topic to avoid confusion.

codemac · 2007-07-19 16:14:24

I think it is reasonable to want all packages to have the same order of variables. Most of us are just cp'ing PKGBUILDs from other packages anyways, just make the one you cp from correct.

One of your points I disagree with is the checksum locations. Not only are checksums not informative to a user reading a PKGBUILD, they don't really describe anything. EVERY other field in a PKGBUILD is useful to read if you are trying to figure out the details of the package. Reading an md5sum doesn't help you in the least. I think things that are in the PKGBUILD for machine reading only should go at the bottom.

The other point I disagree with is about deleting unused variables. This will sound silly at first, but read through with me. Lets say you are reading a PKGBUILD and want to figure out every attribute of the package. We could do the blanket assumption "if it's not listed, then I'll assume it's not needed/unused". Or we could read "install= " which explicitly states there is no install file. Not only that, but now when you add an install file, it's likely that the field is in the right order and less finangling in general. How many AUR users don't know how to use the options array? How many don't know what backup does? Do they know whether force is an option or a field? It may seem like they just just look at the manpage, but I cite the following mantra:

Explicit over implicit

tardo · 2007-07-19 18:31:36

codemac wrote:

I think it is reasonable to want all packages to have the same order of variables. Most of us are just cp'ing PKGBUILDs from other packages anyways, just make the one you cp from correct.
One of your points I disagree with is the checksum locations. Not only are checksums not informative to a user reading a PKGBUILD, they don't really describe anything. EVERY other field in a PKGBUILD is useful to read if you are trying to figure out the details of the package. Reading an md5sum doesn't help you in the least. I think things that are in the PKGBUILD for machine reading only should go at the bottom.
The other point I disagree with is about deleting unused variables. This will sound silly at first, but read through with me. Lets say you are reading a PKGBUILD and want to figure out every attribute of the package. We could do the blanket assumption "if it's not listed, then I'll assume it's not needed/unused". Or we could read "install= " which explicitly states there is no install file. Not only that, but now when you add an install file, it's likely that the field is in the right order and less finangling in general. How many AUR users don't know how to use the options array? How many don't know what backup does? Do they know whether force is an option or a field? It may seem like they just just look at the manpage, but I cite the following mantra:
Explicit over implicit

I think I'd be perfectly happy with these two.

ekerazha · 2008-01-11 09:38:58

Inside my PKGBUILDs I put my website address and *not* my e-mail address. Why? Because clear, plain text e-mail addresses are the dream of every SPAMMER (and so are e-mail addresses with "at" instead of "@").

Arch Linux

#26 2007-07-17 10:29:28

Re: PKGBUILD advice

#27 2007-07-17 12:18:06

Re: PKGBUILD advice

#28 2007-07-17 12:32:37

Re: PKGBUILD advice

#29 2007-07-17 13:23:39

Re: PKGBUILD advice

#30 2007-07-17 13:29:11

Re: PKGBUILD advice

#31 2007-07-17 14:17:27

Re: PKGBUILD advice

#32 2007-07-17 15:41:35

Re: PKGBUILD advice

#33 2007-07-17 17:18:23

Re: PKGBUILD advice

#34 2007-07-17 17:31:04

Re: PKGBUILD advice

#35 2007-07-17 17:40:48

Re: PKGBUILD advice

#36 2007-07-17 17:49:03

Re: PKGBUILD advice

#37 2007-07-18 05:06:57

Re: PKGBUILD advice

#38 2007-07-18 08:46:46

Re: PKGBUILD advice

#39 2007-07-18 09:00:32

Re: PKGBUILD advice

#40 2007-07-18 15:09:00

Re: PKGBUILD advice

#41 2007-07-19 16:14:24

Re: PKGBUILD advice

#42 2007-07-19 18:31:36

Re: PKGBUILD advice

#43 2008-01-11 09:38:58

Re: PKGBUILD advice

Board footer