On Fri, Jul 15, 2016 at 4:30 AM, Juan Francisco Cantero Hurtado < [email protected]> wrote:
> On 14/07/16 21:44, Benoît Minisini wrote: > > Le 14/07/2016 02:28, Juan Francisco Cantero Hurtado a écrit : > >> Hi. In the page http://gambaswiki.org/wiki/howto/package , you give > some > >> indications to the packagers. You want one package per component. > >> > >> That's okay but I don't understand why are you bundling every component > >> in one "big" tarball without a configure script. You could create > >> individual tarballs with the configure script generated. That would make > >> quite easy to comply with your wishes. > >> > >> Some packaging tools make pretty hard to split big tarballs in small > >> packages. Specially during the update to a new version. > >> > >> Am I missing something? :) > >> > > > > I don't see what the problem is. Can you elaborate? > > Create one big fat package with tens of dependencies from a big tarball > is quite easy. > > On OpenBSD Ports, when the packagers want to split a package in various, > they use subpackages. The ports use a PLIST file which is a list of > files to include in the package. When subpackages are used, the > packagers need to generate the individual PLISTs by hand (almost 100 in > the gambas case). When the ports are updated to a new version, the > packager needs to generate again the PLIST by hand. > > With small tarballs, the packagers could create individual ports for > every gambas package. The updates and maintenance would be more simple. > The configure scripts would help to save build time in this case. > So instead of one tar ball, people would need to download and unpack multiple tar balls and then compile them individually!? I don't see how this would make things *easier*. PLIST thing sounds like broken packaging system. Jussi ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ Gambas-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gambas-user
