You are not logged in.
Pages: 1
Hi,
I'm currently trying to compile/package some programs with makepkg. Of course there are some questions that have turned up:
1. Trying to package sim 0.9.2 - it requires flex 2.5.31 to compile whereas .27 is in Current. Same for Automake the other way round - 1.8.x is in Current whereas Sim only rules with 1.7.x
Both are no real problems - you just have to get the right versions. But do I have to mention these version-dependencies in my PKGBUILD somewhere?
2. Sim can be compiled with or without kde support. How is the naming scheme here?
Should I create a version "sim" with kde and a version "sim-qt" with qt-only, or what exactly?
3. Sim requires Sablot http://www.gingerall.com/charlie/ga/xml/p_sab.xml
The Problem here is that the Sablot source archives you can get start with a major S - http://download-1.gingerall.cz/download … 0.1.tar.gz
Now this only works if I set the packagename in my PKGBUILD to Sablot instead of sablot - quite inconsistent.
namcap also doesn't like Sablot but would rather prefer sablot as name - what can I do?
4. I also packaged the Toshiba Laptop Utilities from http://www.buzzard.org.uk/toshiba
There the problem is that this Utilities require the Kernel Option CONFIG_TOSHIBA to be turned on (or the Module loaded) to work.
Can I just upload the package nevertheless or should I somehow-somewhere include a warning so people see they have to include this kernel option. Or could someone add this to the default archlinux kernel?
Peschmä
Offline
1. Trying to package sim 0.9.2 - it requires flex 2.5.31 to compile whereas .27 is in Current. Same for Automake the other way round - 1.8.x is in Current whereas Sim only rules with 1.7.x
Both are no real problems - you just have to get the right versions. But do I have to mention these version-dependencies in my PKGBUILD somewhere?
The best solution would be to try and get sim to work with the existing versions of flex and automake. Can you tweak sim's configure/Makefile, or is the problem much deeper, C source/headers?
2. Sim can be compiled with or without kde support. How is the naming scheme here?
Should I create a version "sim" with kde and a version "sim-qt" with qt-only, or what exactly?
What kind of kde support is it? If it's just adding an entry to the menu or something, I'd say leave it out. If it integrates with drag-n-drop or something like that, then probably two packages. sim and sim-kde.
3. Sim requires Sablot http://www.gingerall.com/charlie/ga/xml/p_sab.xml
The Problem here is that the Sablot source archives you can get start with a major S - http://download-1.gingerall.cz/download … 0.1.tar.gz
Now this only works if I set the packagename in my PKGBUILD to Sablot instead of sablot - quite inconsistent.
namcap also doesn't like Sablot but would rather prefer sablot as name - what can I do?
Name the package sablot. In your PKGBUILD, you'll just have to refer to the source with the full name rather than using $pkgname. If it wants to install the binary as Sablot, leave it as-is.
4. I also packaged the Toshiba Laptop Utilities from http://www.buzzard.org.uk/toshiba
There the problem is that this Utilities require the Kernel Option CONFIG_TOSHIBA to be turned on (or the Module loaded) to work.
Can I just upload the package nevertheless or should I somehow-somewhere include a warning so people see they have to include this kernel option. Or could someone add this to the default archlinux kernel?
Create a UTIL.install (substitute UTIL with the name of your package) script and echo a warning message to the user about this package requiring the CONFIG_TOSHIBA kernel option.
Follow the link below, sign up, and accept one promotional offer. If I can get five suckers (err... friends) to do this, I'll get a free iPod. Then you too can try to get a free iPod. Thanks! http://www.freeiPods.com/?r=11363142
Offline
The best solution would be to try and get sim to work with the existing versions of flex and automake. Can you tweak sim's configure/Makefile, or is the problem much deeper, C source/headers?
Automake shouldn't be too much of a problem. But flex leads to really nasty compile errors. Is flex gonna be updated soon?
Can I just add a compile-time dependency to a newer flex version (which is not in current/extra)?
What kind of kde support is it? If it's just adding an entry to the menu or something, I'd say leave it out. If it integrates with drag-n-drop or something like that, then probably two packages. sim and sim-kde.
I dunno. I think I'll do both once I've got it working.
Name the package sablot. In your PKGBUILD, you'll just have to refer to the source with the full name rather than using $pkgname.
Well - if I do so it fetches the sources correctly. But already the extracting fails as it tries to extract sablot.tar.gz instead of Sablot.tar.gz
Is there a possibility to add a pre-extracting script which moves the file Sablot.tar.gz to sablot.tar.gz?
If it wants to install the binary as Sablot, leave it as-is.
I don't understand this. Could you explain me what you mean by "it wants to install the binary as Sablot"?
Create a UTIL.install (substitute UTIL with the name of your package) script and echo a warning message to the user about this package requiring the CONFIG_TOSHIBA kernel option.
Thanks. I'll do so as soon as I got my kernel recompiled and the whole thing tested.
When it's done - can I just upload the packages and the maintainers will take care of it as mentioned in the Documentation or do I have to inform one of the maintainers first?
Peschmä
Offline
1. there is a feature on the web page that you can flag packages as out of date. use that and don't upload sim until it is upgraded. also make sure that you set the minimum version of flex that this package requires. determine if flesx is runtime or makedepends. for automake it is likely a stupid error in one of their compiling scripts.
2. persoanlly i don't like making packages exclusive to a desktop unless there is no choice. if the kde "support" is merely menus you can use the post install scipts to detect kde and then create the manu entries. making many versions of one package is a waste of bandwidth and time if one package can be made to work for all cases.
3. all packages must be in lower case. some developers are really annoying though and break from standards and capitalized their source tarballs (and don't put in the version numbers as well which is a very large pain in the ass for package maintainers as they then have to remove the old cached source tarball so the new one will download). to answer your question. if the result sablot directory is called Sablot after untarring simply accomodate for it in you PKGBUILD like so :
cd $startdir/Sablotif you have any questions on how to deal with capitals in package names please look through abs there are LOTS of instances of it.
4. i am not sure but i thought that one of the turs had created a toshiba utilities package. maybe give a check through the TURS, staging and the arch repos before uploading this package. duplication of packages can be such a pain to deal with for the maintainers.
AKA uknowme
I am not your friend
Offline
1. there is a feature on the web page that you can flag packages as out of date. use that and don't upload sim until it is upgraded. also make sure that you set the minimum version of flex that this package requires. determine if flesx is runtime or makedepends. for automake it is likely a stupid error in one of their compiling scripts.
Hum. But as flex ist only a compile-time dependency I can already upload it or rather not?
It's already flagged.
2. persoanlly i don't like making packages exclusive to a desktop unless there is no choice. if the kde "support" is merely menus you can use the post install scipts to detect kde and then create the manu entries. making many versions of one package is a waste of bandwidth and time if one package can be made to work for all cases.
Well I'll have a look at it. If it looses functionality with Qt alone I'll do both. (Shouldn't be the case as there's also a Qt-only based windows version
3. all packages must be in lower case. some developers are really annoying though and break from standards and capitalized their source tarballs ... to answer your question. if the result sablot directory is called Sablot after untarring simply accomodate for it in you PKGBUILD like so :
if you have any questions on how to deal with capitals in package names please look through abs there are LOTS of instances of it.
I'll look at abs. Unluckily it doesn't even untar...
[edit] Wrong it works. Thanks![/edit]
4. i am not sure but i thought that one of the turs had created a toshiba utilities package. maybe give a check through the TURS, staging and the arch repos before uploading this package. duplication of packages can be such a pain to deal with for the maintainers.
Well I'm not yet really familar with the project. Thus I just discovered TURS - but I don't see this package there.
Peschmä
Offline
sure if flex is just build time depends that gives you alot of leeway. i w ould upload the finished package.
sounds like you are well on your way to with respect packaging. it is great that you consider alot when you are building. generally packagers try and just include the most popular features of a given package (or the non commonly featured ones that just make sense) after all anyone id free to recompile a package using abs at any time. this is one of the arch features that allowws it to be both light an very configurable. a good build system goes a long way.
i am sure the entire community will appreciate any contributions you make. thanks for your time.
(btw you can use the bug tracker to request that that kernel option be enbled in the future)
AKA uknowme
I am not your friend
Offline
Pages: 1