Still progressing for the code review........
If the package fails to build, the package is still inserted in the
/etc/oscar/oscar-packages/.oscar_pkgs
1/ I need to fix all lines were errors are reported but the code continues to
run.
2/ I need to fix this: if compilation fails while we are in the --force
situation, try to remove the entry in /etc/oscar/oscar-packages/.oscar_pkgs
just in case it did build before....
packman needs review regarding verbosity.....(seems hardcoded)...
Olivier.
----- Mail original -----
> De: "DongInn Kim" <di...@cs.indiana.edu>
> À: oscar-devel@lists.sourceforge.net
> Envoyé: Mardi 9 Avril 2013 17:04:55
> Objet: Re: [Oscar-devel] RE : oscar-packager: code review in
> progress.
> > Another feature that could help later would be to rework the
> > /etc/oscar/oscar-packager directory structure.
>
> > just like /etc/yum.repos moved to /etc/yum.repos.d/*.repo we could
> > have
>
> > /etc/oscar/oscar-packager/*unstable.cfg moved to
> > /etc/oscar/oscar-packager/unstable/{core,included,contributed}/{one
> > .cfg per package containing both main package and meta package}
>
> > content could be:
>
> > source = svn, http://.....
>
> > opkg = svn, http://.….
>
> Yes, I like this idea. It seems to have many files on each directory
> /{core,included,contributed} repeatedly but it should be fine.
> Or maybe, we have
> /etc/oscar/oscar-packager/<version_name>/{core,included,contributed}.cfg,
> each of which has the list of packages with the current format.
> > - the <package_name>.cfg: can contain a src.rpm: what should we do
> > if
> > under debian......Problem. here. If we have a tarball, then we can
> > build debian package....
>
> > Question: do you think that we could enhance the package.cfg with
> > sections so different sources could be used([rhel|fc:*:*] source=
> > ... [debian:*:*])?
>
> That sounds good to me. This way, we can avoid all the compilation
> issues for the different distros.
> Regards,
> --
> - DongInn
> On Apr 9, 2013, at 10:01 AM, LAHAYE Olivier < olivier.lah...@cea.fr >
> wrote:
> > Hi DongInn,
>
> > I'm still in oscar-packager code. bin/oscar-packager is mostly
> > clean,
> > lib/Packager.pm is 80% clean
>
> > but Packman.pm is not clean and some problems are are here
> > (dependancies installation failure codes lost?).
>
> > I'm ok with all the points you've listed.
>
> > Another feature that could help later would be to rework the
> > /etc/oscar/oscar-packager directory structure.
>
> > just like /etc/yum.repos moved to /etc/yum.repos.d/*.repo we could
> > have
>
> > /etc/oscar/oscar-packager/*unstable.cfg moved to
> > /etc/oscar/oscar-packager/unstable/{core,included,contributed}/{one
> > .cfg per package containing both main package and meta package}
>
> > content could be:
>
> > source = svn, http://.....
>
> > opkg = svn, http://.....
>
> > Want a new contributed package => add the
> > new_contributed_package.cfg
> > into /etc/oscar/oscar-packager/unstable/contributed/ and start
> > oscar-packager...
>
> > => For oscar7 ;-) (before that there are some bugs to fix).
>
> > Regarding the build process......
>
> > I have always in mind the debian side of things.......And it's not
> > an
> > easy point as debian doesn't have the .spec concept.
>
> > Thus, for the moment, I'd like to avoid removing support for the
> > Makefiles. I've disabled all calls for the rpm: rule when relevant,
> > but for the deb side, I can't tell, I'd need to work on my ubuntu
> > VM.
>
> > - the build.cfg is optional for the moment: no build.cfg => no
> > dependancies and the build is done using the make command as we
> > don't know where is the source...
>
> > - the <package_name>.cfg: can contain a src.rpm: what should we do
> > if
> > under debian......Problem. here. If we have a tarball, then we can
> > build debian package....
>
> > Question: do you think that we could enhance the package.cfg with
> > sections so different sources could be used([rhel|fc:*:*] source=
> > ... [debian:*:*])?
>
> > - The Makefile: used in components like oscar-base, opkgc, ...So
> > disabling it may not be a good idea (at least until build.cfg and
> > <package_name>.cfg are created.
>
> > For the moment, I think that the debian side is not broken (or if
> > it
> > is broken, it's easy to fix). I'll work on that soon. One thing is
> > sure, many packages were not available under debian, so when needs
> > to be checked in the 1st place is when starting oscar-packager, how
> > will it react toward all packages where I added a build.cfg and all
> > packages added. (I think that the most common problems will be the
> > require: section in build.cfg that are either not available or
> > wrong.
>
> > I'll work on that just after fixing oscar-packager.
>
> > Regards,
>
> > Olivier.
>
> > --
>
> > Olivier LAHAYE
>
> > CEA DRT/LIST/DCSI/DIR
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for
> building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free
> account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Oscar-devel mailing list
> Oscar-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oscar-devel
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Oscar-devel mailing list
Oscar-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oscar-devel
