FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 07-11-2012, 10:53 PM
"Simon A. Erat"
 
Default Script-Tools, which location?

Heyas
As i'm new to packaging, specificly to linux, i am a little confused at this moment.I have my scripts (kind of framework, but for any enduser they are just tools) which i'd like to be shiped with Fedora,*however, until now i was thinking like:
My Package = Additional Software = /usr/share/%name.
Now that i had opened a Review Request (https://bugzilla.redhat.com/show_bug.cgi?id=835089), someone asked my whe i didnt pack my scripts into /usr/bin.
Allthought i like this idea, i do not feel that this would be 'clean', as my script tools base upon a directory structure, while there are no directories in /usr/bin.
From the same person i was told that /etc/profile.d/%name.sh would not be a good solution as it wont work with csh, zsh, with which i agree, but couldnt think of a better solution until now.

----------All above here is the actual question----------Now the idea came up to place the 'base-script' (st) in /usr/bin, while everything else would be in a folder somewhere. However, this has a hughe drawback, as it (the script tools) wont work in this mixed up (split away) environment.
Until now, one could have been sure, that in any case if i move the directory the scripts tools are in, anywhere else, one could just execute the main script and everything kept working.This was achieved by symlinking the actualy path to /usr/share/%name, of course only if it wasnt installed there using rpm/yum (default).

Now after all this crapy text (its past midnight here), according to the feedback (very little) i have recieved so far,i do need feedback/info, from someone capable handling complex bash script structures across folders, using other scripts are libraries, offering the users to write their own libs and scripts.
Further, it takes some use of 'configuration' files, uses some sort of templates and lots of other stuff.
It is NOT an easy task, to review, or to understand how it works, or to actualy give any kind of advice.
I do know and understand this, thus i would appreciate any usefull feedback even more for the very same reason.
For more info about this package, please have a look at*http://sea.hostingsociety.com/?p=Script-Tools&stc=*many, but not all, things are explained there, or at least try to be there.
Have i mentioned, i lack of feedback/questions so i could not write the readme appropriate to the 'demand' of explanation.
Where would be the proper place to put/package my script tools to?

Thank you in advance for any hints, advices, questions or suggestions.Kind regards~sea~
--
Simon A. Erat (sea)
Switzerland
----------------
FAS: sea

IRC: seasc



--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 07-12-2012, 11:00 AM
Michael Schwendt
 
Default Script-Tools, which location?

On Thu, 12 Jul 2012 00:53:03 +0200, Simon A. Erat wrote:

> Heyas
>
> As i'm new to packaging, specificly to linux, i am a little confused at
> this moment.
>
> I have my scripts (kind of framework, but for any enduser they are just
> tools) which i'd like to be shiped with Fedora, however, until now i was
> thinking like:
> My Package = Additional Software = /usr/share/%name.

It cannot be generalized like that. When deciding where to store files,
one must tell what type of files they are. Skimming over the FHS can help
to find the proper location, as the packaging for Fedora can get a lot
more trouble-some, if a software project installs into uncommon locations
or violates the FHS even. /usr/share/ is for architecture-independent
read-only data files.

> Now that i had opened a Review Request (
> https://bugzilla.redhat.com/show_bug.cgi?id=835089), someone asked my whe i
> didnt pack my scripts into /usr/bin.

/usr/bin sounds reasonable.

At least, it should be easily possible for your project to store small
scripts in /usr/bin, which know about their home directory, from where to
load supporting files (including additional hidden scripts not to make
available in $PATH).

> Allthought i like this idea, i do not feel that this would be 'clean', as
> my script tools base upon a directory structure, while there are no
> directories in /usr/bin.

That sounds a bit like a design mistake. Can you tell why you think you
would need a directory structure below /usr/bin and not elsewhere?

> From the same person i was told that /etc/profile.d/%name.sh would not be a
> good solution as it wont work with csh, zsh, with which i agree, but
> couldnt think of a better solution until now.

That's inaccurate. Adjusting $PATH via profile.d scripts is a good
solution for *some* projects, e.g "ccache", but it ought to be an exception
(and there's a reason why "ccache" does it like that). It doesn't sound
correct/ideal/elegant for your scripts.

> Now the idea came up to place the 'base-script' (st) in /usr/bin, while
> everything else would be in a folder somewhere. However, this has a hughe
> drawback, as it (the script tools) wont work in this mixed up (split away)
> environment.

As above, a design mistake?

> Until now, one could have been sure, that in any case if i move the
> directory the scripts tools are in, anywhere else, one could just execute
> the main script and everything kept working.

The scripts would stay in /usr/bin, be available for execution by every
user, and if you moved anything at all with an update of the software in
an update of the RPM package, you would replace the script files. Why would
the new files not work anymore (or not know about changed directories)?

> This was achieved by symlinking the actualy path to /usr/share/%name, of
> course only if it wasnt installed there using rpm/yum (default).

Perhaps you could explain in more detail what problem you're trying to
solve?

> Further, it takes some use of 'configuration' files, uses some sort of
> templates and lots of other stuff.

That's not unusual.

--
Fedora release 17 (Beefy Miracle) - Linux 3.4.4-5.fc17.x86_64
loadavg: 0.19 0.36 0.49
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 07-12-2012, 10:12 PM
"Simon A. Erat"
 
Default Script-Tools, which location?

First of all, whats the acronym FHS standing for?
You asked for a better explanation, i hope i can deliver it.
Script-Tools has several purposes and ideas behind its creation.
1) At first it was designed to be distributed as tarball, i want to keep this option, as this allows an easy port/install to any other linux distro.* *(just extract anywhere of your choice and run from there)
2) Easy - Reusability3) Easy - Set and forget
As i was told, Fedora doesnt allow to install packages at custom locations, allthough it describes how-to in the docs... weird imho...
If i take this as a fact, and refer to your saying, /usr/share/%name is ment for read-only files, it would be a good match after all, as i currently*save any data in $HOME/bin/$USER-libs, and offering $HOME/bin/$USER-scripts to be used for custom scripts using the functions which Script-Tools provides.
But... as i will going to get the use of /usr/bin for the start-script, i wonder if $HOME/bin/$USER-libs|*-scripts is acceptable, specialy since none of them are required. However, i'll have to rewrite the dev section, so it stores the project|rpm|sourceforge info somewhere in $HOME/.config or so?

> That sounds a bit like a design mistake. Can you tell why you think you
> would need a directory structure below /usr/bin and not elsewhere?
After a rethought, the only thing that could be placed in /usr/bin would be the starting script, and those files in $stDir/scripts.
And that file can refer to /usr/share/%name to find all sub-folders /files.The other 'single' scripts, which until now reside in $stDir/scripts do not use the functions the Script-Tools provide, so that wouldnt be a problem.

Placing the main script (or a symlink) to /usr/bin would also no longer need /etc/profile.d/%name.sh.Got to say, i start liking this idea, until now i didnt feel comfortable doing so, as i thought "its just my script, nothing high-end-professional/required".

Gosh this is more of a chat than an explanation, i'm sorry.
2012/7/12 <packaging-request@lists.fedoraproject.org>

Message: 6

Date: Thu, 12 Jul 2012 13:00:15 +0200

From: Michael Schwendt <mschwendt@gmail.com>

To: packaging@lists.fedoraproject.org

Subject: Re: [Fedora-packaging] Script-Tools, which location?

Message-ID: <20120712130015.5b0810e8@gmail.com>

Content-Type: text/plain; charset=US-ASCII



On Thu, 12 Jul 2012 00:53:03 +0200, Simon A. Erat wrote:



> Heyas

>

> As i'm new to packaging, specificly to linux, i am a little confused at

> this moment.

>

> I have my scripts (kind of framework, but for any enduser they are just

> tools) which i'd like to be shiped with Fedora, however, until now i was

> thinking like:

> My Package = Additional Software = /usr/share/%name.



It cannot be generalized like that. When deciding where to store files,

one must tell what type of files they are. Skimming over the FHS can help

to find the proper location, as the packaging for Fedora can get a lot

more trouble-some, if a software project installs into uncommon locations

or violates the FHS even. /usr/share/ is for architecture-independent

read-only data files.



> Now that i had opened a Review Request (

> https://bugzilla.redhat.com/show_bug.cgi?id=835089), someone asked my whe i

> didnt pack my scripts into /usr/bin.



/usr/bin sounds reasonable.



At least, it should be easily possible for your project to store small

scripts in /usr/bin, which know about their home directory, from where to

load supporting files (including additional hidden scripts not to make

available in $PATH).



> Allthought i like this idea, i do not feel that this would be 'clean', as

> my script tools base upon a directory structure, while there are no

> directories in /usr/bin.



That sounds a bit like a design mistake. Can you tell why you think you

would need a directory structure below /usr/bin and not elsewhere?



> From the same person i was told that /etc/profile.d/%name.sh would not be a

> good solution as it wont work with csh, zsh, with which i agree, but

> couldnt think of a better solution until now.



That's inaccurate. Adjusting $PATH via profile.d scripts is a good

solution for *some* projects, e.g "ccache", but it ought to be an exception

(and there's a reason why "ccache" does it like that). It doesn't sound

correct/ideal/elegant for your scripts.



> Now the idea came up to place the 'base-script' (st) in /usr/bin, while

> everything else would be in a folder somewhere. However, this has a hughe

> drawback, as it (the script tools) wont work in this mixed up (split away)

> environment.



As above, a design mistake?



> Until now, one could have been sure, that in any case if i move the

> directory the scripts tools are in, anywhere else, one could just execute

> the main script and everything kept working.



The scripts would stay in /usr/bin, be available for execution by every

user, and if you moved anything at all with an update of the software in

an update of the RPM package, you would replace the script files. Why would

the new files not work anymore (or not know about changed directories)?



> This was achieved by symlinking the actualy path to /usr/share/%name, of

> course only if it wasnt installed there using rpm/yum (default).



Perhaps you could explain in more detail what problem you're trying to

solve?



> Further, it takes some use of 'configuration' files, uses some sort of

> templates and lots of other stuff.



That's not unusual.



--

Fedora release 17 (Beefy Miracle) - Linux 3.4.4-5.fc17.x86_64

loadavg: 0.19 0.36 0.49





------------------------------



--

packaging mailing list

packaging@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/packaging



End of packaging Digest, Vol 89, Issue 6

****************************************



--
Simon A. Erat (sea)
Switzerland
----------------
FAS: sea
IRC: seasc



--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 07-12-2012, 11:49 PM
Björn Persson
 
Default Script-Tools, which location?

Simon A. Erat wrote:
> First of all, whats the acronym FHS standing for?

The Filesystem Hierarchy Standard:
http://www.pathname.com/fhs/pub/fhs-2.3.html

It's linked from the Packaging Guidelines, which I hope you read before you
made your package:
https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout

> 1) At first it was designed to be distributed as tarball, i want to keep
> this option, as this allows an easy port/install to any other linux distro.
> (just extract anywhere of your choice and run from there)

It's easier to do that if you give your relocatable directory tree an FHS-like
structure, with a prefix that can be set to "/usr", "/usr/local",
"/opt/Simon's-script-tools" or anything else, and place scripts in $prefix/bin,
read-only data in $prefix/share et cetera.

You may still find that you need to make your scripts capable of adapting a bit
to different directory layouts.

> i currently save any data in $HOME/bin/$USER-libs, and offering
> $HOME/bin/$USER-scripts to be used for custom scripts using the functions
> which Script-Tools provides.

You shouldn't make subdirectories under $HOME/bin any more than under
/usr/bin. Although users' home directories are less standardized than system
directories, $HOME/bin is typically used for the users' own programs that they
want to be able to run from a command prompt. Programs in subdirectories
wouldn't be found unless the users added the subdirectories to PATH.

Also, anything that ends with "libs" seems like a bad name for a directory to
save data in.

Björn Persson
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 

Thread Tools




All times are GMT. The time now is 02:39 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org