[En-Nut-Discussion] RPM packages
Marcin Trendota
moonwolf.ethernut at gmail.com
Wed Jan 29 10:04:23 CET 2014
On Sunday 12 of January 2014 11:55:08 PM Ole Reinhardt writes:
> > I tried to extract conf/ dir to /usr/share/ also without luck (i
> > believe configuration files should be there, not in source tree).
> Which files exactly do you want to extract from the main repository
> tree? And all in all, where do you plan to place the files at all?
As i stated i wanted to create FHS compliant RPMs - i have feeling it's
The Proper Way. So I believe all conf/* files belongs somewhere to
/usr/share/nutos.
> I definately would not place any include files to /usr/include for
> example, as these are not target specific headers, but are headers of
> a cross compile environment.
> In my eyes the whole thing should be copied as a whole tree to
> /opt/ethernut-5.1.0 for example.
/opt shouldn't be use by packages i think.
But maybe packagers of AVR did it right? They put all things in
/usr/avr...
> Only the real binaries (qnutconf, crurom, etc...) I would install to
> /usr/bin
Agreed.
> You could think about installing the *.cong files from nut/conf to
> /usr/share/ethernut-5.1.0/conf for example. But all other files in
> nut/conf need to stay where they are, as the configuator (and its
> internal lua interpreter) expects them there.
That's why i failed to extract those files.
> > I wonder if it's worth to modificate configuration scripts /
> > makefiles to allow those extractions and make tweaks unnecessary?
> > To be honest i don't know which files will need modification and
> > maybe this could be done by some options passed to autogen.sh /
> > configure scripts?
> At least the modifications need to stay compatible with what is
> currently existing, as the windows users use the same Makefiles.
> Please keep in mind that under Windows you very likely won't have a
> shell.
That's why it should be done transparently. Don't yet know how,
howewer.
> Personally I even do not see a real need to have a Debian (or RPM)
> package. The package makes much sense for the Nut/OS tools (see
> above), but the sourcecode I always want to have in close relation
> to my development project. Often I also copy the Nut/OS tree to the
> project repo as well, as we need to have a defined revison in our
> project.
I see advantages. Nut/OS changes often - and in places that are our
interest (STM). There are good coders that have problems with keeping
with newest version. Putting it into repository will help them much.
Also - i think - having Nut/OS packaged lowers entry barrier for
programmers. They don't have to keep looking for new versions.
> Again, the Nut/OS tools stay the same most time, so these could be
> well installed in the system.
Well agreed again. As i said - i've created those RPMs and they looks
OK, for now i will leave them as they are. I must postpone further work
for some time, so maybe i will rethink some ideas.
Just had some thoughts i wanted to share with developers (:)
--
Best regards
Marcin Trendota
More information about the En-Nut-Discussion
mailing list