[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