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 - Reusability
3) 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(a)lists.fedoraproject.org>
> Message: 6
> Date: Thu, 12 Jul 2012 13:00:15 +0200
> From: Michael Schwendt <mschwendt(a)gmail.com>
> To: packaging(a)lists.fedoraproject.org
> Subject: Re: [Fedora-packaging] Script-Tools, which location?
> Message-ID: <20120712130015.5b0810e8(a)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(a)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