You are not logged in.

#1 2012-05-11 22:38:19

tybo
Member
Registered: 2012-05-03
Posts: 21

Interactive PKGBUILD

Hi,

I would like to have your advice on the following point:

I would like to make a package that could possibly meet different configurations depending on the computer it is being build for.

I would therefore like to know if there is a way -- and if such things would be acceptable for an AUR package -- to obtain user input when the PKGBUILD script is not capable of taking a decision automatically.

This could allow to build interactive PKGBUILD scripts that would produce customized packages depending on the user's choices.

What do you think?

Is it better to provide the choice by splitting the package into several packages having slightly different configurations?
Is it better to create a meta-package that just tells the user which of the specifically tailored packages he is supposed to pick?

Thanks in advance for you advice.

Offline

#2 2012-05-11 23:19:15

xx4h
Member
Registered: 2011-02-28
Posts: 21
Website

Re: Interactive PKGBUILD

For me interactive is just fine. don't know if it is acceptable for AUR package.

but one more question you have to ask your self.
Could a user be interested (and is it possible) to install this package with another config parallel?
if this question can be answered with "yes". maybe splitting it up is the better choice.


Sysprofile
xx4h freenode #archlinux/#archlinux-aur/#archlinux-offtopic
BitCoin-Address: 13eaEB8YK5heFwXWieL8bZXXPq8fgbS8Kx

Offline

#3 2012-05-12 01:51:36

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: Interactive PKGBUILD

PKGBUILDs should not be interactive. Please don't do this. Make decisions for the user. If they don't like it, they can change the PKGBUILD.

Offline

#4 2012-05-12 02:01:47

drcouzelis
Member
From: Connecticut, USA
Registered: 2009-11-09
Posts: 4,092
Website

Re: Interactive PKGBUILD

The only package I ever built that required user interaction was the "allegro5" package that used to be in the AUR. It was a pain, confusing, and pointless, and the version that's in the official Arch Linux repositories doesn't require user interaction (of course).

Could you provide more details about the packages you're making, and why you think user interaction might be needed? Maybe somebody already solved that problem in some other package.

Offline

#5 2012-05-12 02:56:18

Allan
Pacman
From: Brisbane, AU
Registered: 2007-06-09
Posts: 11,365
Website

Re: Interactive PKGBUILD

falconindy wrote:

PKGBUILDs should not be interactive. Please don't do this. Make decisions for the user. If they don't like it, they can change the PKGBUILD.

^ This.

Offline

#6 2012-05-12 05:34:29

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 7,354

Re: Interactive PKGBUILD

Allan wrote:
falconindy wrote:

PKGBUILDs should not be interactive. Please don't do this. Make decisions for the user. If they don't like it, they can change the PKGBUILD.

^ This.

You could of course use bash variables etc. to allow the user to easily change some things (my linux-ice package does that), but the PKGBUILD should NOT be interactive in any way.


Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

#7 2012-05-12 08:56:30

tybo
Member
Registered: 2012-05-03
Posts: 21

Re: Interactive PKGBUILD

Thanks for your replies. So no interaction it will be.

The package I am thinking about is supposed to install itself in the JRE directory (java). Some configuration have a JAVA_HOME variable set, which allows the PKGBUILD to decide for the user, but some do not have it. One could even have different JREs installed (openjdk-6 and openjdk-7 for instance).

Perhaps the solution is to split the package into several specialized packages (one for openjdk-6, one for openjdk-7) plus one general-purpose package trying to install itself using the JAVA_HOME environment variable.
I could display an error message and "exit 1" if the variable is not properly set, and advice the user to define it or choose one of the specialized packages...

What do you think?

Offline

#8 2012-05-12 16:00:34

drcouzelis
Member
From: Connecticut, USA
Registered: 2009-11-09
Posts: 4,092
Website

Re: Interactive PKGBUILD

You still didn't say what the package is, or what type of application it is. wink

If it's a Java application, can't it run from anywhere?

If it's a Java library, can't you install those anywhere, and then tell the user to include it in their classpath?

Are there any other Arch Linux packages that have a similar situation?

I don't know enough about Java to know about any other scenarios...

Offline

#9 2012-05-12 16:06:03

tybo
Member
Registered: 2012-05-03
Posts: 21

Re: Interactive PKGBUILD

You are right, sorry. The package I am thinking about is java3d, which is currently orphan.
I thought I should take it and try to enhance the way the PKGBUILD installs the library in the jre.

It currently assumes the JAVA_HOME variable is defined. I would like at least to change it so that it produces an error message and advises the user to use another package (such as java3d-openjdk6) when the variable is not defined.

Perhaps there is a smarter way of doing this PKGBUILD. In that case I am not the one who should maintain the package, because obviously I know nothing but the simple, brutal way of fixing it... wink

Offline

#10 2012-05-12 17:37:22

drcouzelis
Member
From: Connecticut, USA
Registered: 2009-11-09
Posts: 4,092
Website

Re: Interactive PKGBUILD

It's good of you to take up an orphan package. smile I did some research. My conclusion is that making Java packages are confusing and Java3D is confusing. O_o Here is my opinion:

Yes, create separate packages to be used for different versions of the JRE. Even so, don't overwork yourself; just create the version that you need. (I assume you want to also USE Java3D wink) So, create the "java3d-openjdk6" (or whatever) package. Additionally, make that package depend on exactly what it needs: "openjdk6", and not "java-runtime".

The idea is that a package on one computer should be the same as on another computer, whether it comes from the official repositories or the AUR. The PKGBUILD file says exactly what packages are needed to build / use it, and after the package is build it should be exactly the same as the package that anyone else has built.

I also noticed the official Java3D website appears to be down, and Java3D doesn't appear to be developed anymore, but, whetever. tongue

Anyway, that's just my opinion. What do you think?

Offline

#11 2012-05-13 16:20:01

tybo
Member
Registered: 2012-05-03
Posts: 21

Re: Interactive PKGBUILD

I guess you are right. The package for openjdk6 already exists. The job is done wink

Thanks a lot again for your advice.

Offline

Board footer

Powered by FluxBB