Re: Looking for a committer net-mgmt/prometheus
Hi! > I just updated https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212468 patch > attachment to build the latest release of prometheus. It's now 1.2.1 Well, the version number in the patch was 1.1.3, but changing that to 1.2.1 was easy, test-building was OK, so: done. > Can I get a committer to review, and possibly commit? This new port request > and my other one (node_exporter: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212467) have both been > open since Sep 9th. Also done. -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Looking for a committer net-mgmt/prometheus
Hi All, I just updated https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212468 patch attachment to build the latest release of prometheus. It's now 1.2.1 Can I get a committer to review, and possibly commit? This new port request and my other one (node_exporter: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212467) have both been open since Sep 9th. Thanks! Jev ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
On Fri, 14 Oct 2016, David Demelier wrote: > It's not writing a port that is complicated, it's the whole > infrastructure. You should see the Macports infrastructure... Fairly easy for the end user, but those developers sweat blood to make it so. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
The Unique iMarketing Center app to send bulk SMS and email
___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
On 14/10/2016 4:27 AM, Matthieu Volat wrote: On Fri, 14 Oct 2016 13:05:35 +0200 David Demelier wrote: 2016-10-14 11:22 GMT+02:00 Baptiste Daroussin : It is imho doable in both sides. We could imagine tagging the plist/manifest so pkg can allow a user to install only the things tagged as runtime for exemple which would do the job. for what Julian is asking for beside adding lots of complexity pkg(8) and adding a nightmare in the solver. That would "please" the people that want "hey keep the giant flat package as it is better for dev given I don't have to install the -devel version something" and the people wanting fine grain selection if they need to. But on the ports side that would be a nightmare having to tag all the plist (and this cannot be automated because there are to many corner cases. IIRC, rpm builders have script that automate this by finding files in standard directories. Probably by checking in the stage a include/ directory and "tag" it as the development part. Unless things changed very recently, not quite : you have to pile subpackage declaration and files sections according to the subpackages you create. The only things it has to ease the burden is you can use wildcard patterns to select files. It will be the most smart way of doing this but still require some addition to pkg. Probably like: - pkg install mylib - pkg install -t dev mylib - pkg install -t runtime mylib - pkg install -t dev,runtime,doc mylib Just thinking ;) More options, then more options to `pkg info` to get what was installed when something cannot build, then more pkg search options and manpage because more "-t" flags will be added and we don't know what's needed? I'm glad people are at least thinking about it... I don't think there are so many categories. Are we installing onto a development machine, user machine, or an appliance? appliances don't need man pages. User machines need man pages for programs but not for libraries and developer machines.. everything.. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re[2]: www/magento port outdated
a new port would be quite nice. i am pretty clueless about creating or maintaining one though :( regards, alex -- Originalnachricht -- Von: "Torsten Zuehlsdorff" An: "Alexander Liebau" ; po...@freebsd.org Gesendet: 14.10.2016 12:49:12 Betreff: Re: www/magento port outdated On 14.10.2016 12:15, Torsten Zuehlsdorff wrote: On 14.10.2016 11:13, Alexander Liebau wrote: hello, i would like to ask if it is possible to update the port www/magento to its current version. it is currently on version 1.8.1 which is more than 2 years old. the most recent version would be 2.1.2 or 2.0.10 according to https://www.magentocommerce.com/download There is a PR for an update, but no work happend on it for long time. Oh, i'm sorry, forgot the link: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201709 As you can see there was already a try to bring it to a current (and supported) 1.9.x version, but it failed and the maintainership was dropped. :/ I could help in creating a new port with magento 2. But i have not this much time so it will take a while ;) Greetings, Torsten ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
On Fri, 14 Oct 2016 13:05:35 +0200 David Demelier wrote: > 2016-10-14 11:22 GMT+02:00 Baptiste Daroussin : > > It is imho doable in both sides. > > > > We could imagine tagging the plist/manifest so pkg can allow a user to > > install > > only the things tagged as runtime for exemple which would do the job. for > > what > > Julian is asking for beside adding lots of complexity pkg(8) and adding a > > nightmare in the solver. > > > > That would "please" the people that want "hey keep the giant flat package > > as it > > is better for dev given I don't have to install the -devel version > > something" > > and the people wanting fine grain selection if they need to. > > > > But on the ports side that would be a nightmare having to tag all the plist > > (and > > this cannot be automated because there are to many corner cases. > > IIRC, rpm builders have script that automate this by finding files in > standard directories. Probably by checking in the stage a include/ > directory and "tag" it as the development part. Unless things changed very recently, not quite : you have to pile subpackage declaration and files sections according to the subpackages you create. The only things it has to ease the burden is you can use wildcard patterns to select files. > It will be the most smart way of doing this but still require some > addition to pkg. Probably like: > > - pkg install mylib > - pkg install -t dev mylib > - pkg install -t runtime mylib > - pkg install -t dev,runtime,doc mylib > > Just thinking ;) More options, then more options to `pkg info` to get what was installed when something cannot build, then more pkg search options and manpage because more "-t" flags will be added and we don't know what's needed? -- Matthieu Volat pgpZY_aqAJ_bU.pgp Description: OpenPGP digital signature
Re: harder and harder to avoid pkg
Hi! > > This is an appliance class machine. It has 2G of storage and that has > > to include 2 copies for the OS so we can ping-pong for upgrades. > > I can get > 2GB CPU cache per system (spread over 8+ sockets) these > days. Is it really reasonable to expect port maintainers to take up the > work and classify their maintained ports for you to save you an > additional 2GB of cheap flash storage? Letting the appliance-market slip away to other platforms should be avoided. > At a certain scale those > trade-offs might make sense for you, but I suspect most FreeBSD port > maintainers and FreeBSD users don't mind a few 100 kB of documentation > and headers on their systems. Aren't there easier solutions which don't > require a lot of manual work? Using the pkg-plist of packages by removing those files not in bin/ or lib/ might solve approx. 80% of the problem. Someone's willing to test this 8-} ? -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
On 14/10/2016 09:39, Julian Elischer wrote: On 13/10/2016 10:33 AM, RW via freebsd-ports wrote: On Tue, 11 Oct 2016 11:59:47 -0700 Julian Elischer wrote: As the number of dependencies between packages get ever higher, it becomes more and more difficult to compile packages and the dependence on binary precompiled packages is increased. However binary packages are unsuitable for some situations. We really need to follow the lead of some of the Linux groups and have -runtime and -devel versions of packages, OR we what woudlbe smarter, woudl be to have several "sub manifests" to allow unpacking in different environments. A simple example: libxml2 This package installs include files and libraries and dicumentation etc. yet if I build an appliance , I want it to only install a singe file. /usr/local/lib/libxml2.so.2 What practical problem does installing the include files and man pages cause you? I have to delete them from the appliance I'm building up. So I need to get the manifest, remove the files I want from it, and delete every other file mentioned. This is an appliance class machine. It has 2G of storage and that has to include 2 copies for the OS so we can ping-pong for upgrades. I can get > 2GB CPU cache per system (spread over 8+ sockets) these days. Is it really reasonable to expect port maintainers to take up the work and classify their maintained ports for you to save you an additional 2GB of cheap flash storage? At a certain scale those trade-offs might make sense for you, but I suspect most FreeBSD port maintainers and FreeBSD users don't mind a few 100 kB of documentation and headers on their systems. Aren't there easier solutions which don't require a lot of manual work? * Documentation and source code compresses well. Can you use a read-only lzma or gzip compressed filesystem with GEOM uncompress? * Can you use snapshots (and rerooting) to rollback failed updates instead of keeping two full copies around? -- Jan Bramkamp ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
2016-10-14 11:22 GMT+02:00 Baptiste Daroussin : > It is imho doable in both sides. > > We could imagine tagging the plist/manifest so pkg can allow a user to install > only the things tagged as runtime for exemple which would do the job. for what > Julian is asking for beside adding lots of complexity pkg(8) and adding a > nightmare in the solver. > > That would "please" the people that want "hey keep the giant flat package as > it > is better for dev given I don't have to install the -devel version something" > and the people wanting fine grain selection if they need to. > > But on the ports side that would be a nightmare having to tag all the plist > (and > this cannot be automated because there are to many corner cases. IIRC, rpm builders have script that automate this by finding files in standard directories. Probably by checking in the stage a include/ directory and "tag" it as the development part. It will be the most smart way of doing this but still require some addition to pkg. Probably like: - pkg install mylib - pkg install -t dev mylib - pkg install -t runtime mylib - pkg install -t dev,runtime,doc mylib Just thinking ;) -- Demelier David ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: www/magento port outdated
On 14.10.2016 12:15, Torsten Zuehlsdorff wrote: On 14.10.2016 11:13, Alexander Liebau wrote: hello, i would like to ask if it is possible to update the port www/magento to its current version. it is currently on version 1.8.1 which is more than 2 years old. the most recent version would be 2.1.2 or 2.0.10 according to https://www.magentocommerce.com/download There is a PR for an update, but no work happend on it for long time. Oh, i'm sorry, forgot the link: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201709 As you can see there was already a try to bring it to a current (and supported) 1.9.x version, but it failed and the maintainership was dropped. :/ I could help in creating a new port with magento 2. But i have not this much time so it will take a while ;) Greetings, Torsten ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
On 10/14/16 10:22, Baptiste Daroussin wrote: > We could imagine tagging the plist/manifest so pkg can allow a user to install > only the things tagged as runtime for exemple which would do the job. for what > Julian is asking for beside adding lots of complexity pkg(8) and adding a > nightmare in the solver. > > That would "please" the people that want "hey keep the giant flat package as > it > is better for dev given I don't have to install the -devel version something" > and the people wanting fine grain selection if they need to. > > But on the ports side that would be a nightmare having to tag all the plist > (and > this cannot be automated because there are to many corner cases. You still need something like this whichever way sub-packages are implemented -- compiling and staging the port generates a whole load of files and you somehow have to identify each of them as docs, examples, whatever either for tagging in the plist or for turning into sub-packages. Some of that you can do heuristically, but yeah -- this classification job would be a thing that port maintainers get to enjoy. It should be possible to create meta-packages that do nothing except depend on commonly used combinations of sub-packages as a convenience for people installing software at the command line. For example one that could have the same overall result as installing an all-in-one package at the moment. I believe something like this is planned for the base system packages. > Having the port that grows the feature would be really nice because no work > would be needed on pkg :) and that would reduce cluster package building as we > could merge qt, php etc into one port that builds multiple sub packages. True, that would save a number of repetitive compilations. Of course, what you save by implementing sub-packages you'ld immediately lose (and more) by implementing package flavours. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: gcc5 dependency challenges
On 14/10/2016 6:48 PM, Dewayne Geraghty wrote: > After some rudimentary performance testing I note that we get up > around 3% improvement in application performance when we use gcc5 for > our package builds. > > However building ports with gcc results in gcc5 being a dependency. > Examining ldd, we find that rarely does anything require gcc5's > shared libs for their execution. Even simple things like ftp/wget > and devel/ccache depend on gcc5 for building but NOT runtime. As we > aren't allowed to install compilers onto production systems, what is > the best course of action to address? (We could just install gcc5 and > then remove it but then of course, the base pkg wants to remove > everything (600+ packages) that depends on gcc5!) > > So the question is - how should we build our packages or install them > so that gcc5 is not (unnecessarily) installed? > > We've added to our /etc/make.conf USE_GCC= 5 but I wonder if there's > something like a build_depends mechanism? > > > Background: Our FreeBSD 10.3 Stable uses pkg 1.8.3; whereas ports > uses 1.8.7_3, minor point. > > Why gcc5? Well most ports use clang 3.4.1 to compile, some ports do > use gcc 4.8.5; and if we move to FreeBSD11 then we also need to add > llvm3.6 into the build/migrating equation. So to aid our migration > effort we "think" choosing gcc5 now is a good idea; particularly as > /usr/ports/base/gcc uses gcc 5.4.0 (rather than /usr/ports/lang/gcc > which is 4.8.5) > > All production systems use local package repositories (as heimdal is > widely used as are non-default options). > > Kind regards, Dewayne This (in progress thing) may help: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211154 See dependent Bugzilla issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211079 ./koobs ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: www/magento port outdated
On 14.10.2016 11:13, Alexander Liebau wrote: hello, i would like to ask if it is possible to update the port www/magento to its current version. it is currently on version 1.8.1 which is more than 2 years old. the most recent version would be 2.1.2 or 2.0.10 according to https://www.magentocommerce.com/download There is a PR for an update, but no work happend on it for long time. Also: Magento 2 it nearly completely incompatible with all 1.x versions. It would be wise to create a new port for this! Otherwise all existing users will be in great trouble, especially if the use modules besides the core installation. Greetings, Torsten ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: www/magento port outdated
Hi! > i would like to ask if it is possible to update the port www/magento to > its current version. > it is currently on version 1.8.1 which is more than 2 years old. > the most recent version would be 2.1.2 or 2.0.10 according to > https://www.magentocommerce.com/download Can you provide a patch ? Or run-testing, if a patch is provided ? A link to the changelog ? -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
On Fri, Oct 14, 2016 at 09:54:07AM +0200, Mathieu Arnold wrote: > Le 14/10/2016 à 09:34, Julian Elischer a écrit : > > On 13/10/2016 5:42 AM, David Demelier wrote: > >> 2016-10-12 10:04 GMT+02:00 Andrea Venturoli : > >>> On 10/12/16 09:24, Matthieu Volat wrote: > >>> > And GNU/Linuxes can be a PITA when you have to track -dev(el) packages > (which sometimes really requires -bin, -app or whatever), or worst, > describe > to people how they are supposed to build your software with weird > subpackage > names. > > I really like that ports provides the software project as intended by > upstream (modulo options). > >>> > >>> Just a "me too" here! > >> Could not agree more. > >> > >> Please forget that idea. > >> > >> I just hate having to install libfoo, libfoo-dev, libfoo-dbg, > >> libfoo-doc, libfoo-whatever each time I need to develop on Linux. > >> Please do not transform FreeBSD as a Linux distribution :) > >> > >> I love the way FreeBSD and some very sparse Linux distributions > >> provide the packages exactly how it would be installed by hand (= > >> vanilla). > >> > >> FreeBSD offers some options and very few changes for better > >> integration but packages are provided vanilla. You want a package? You > >> install /packagename/ nothing more, nothing less. I really would like > >> to see simple vanilla packages for the next 10 years. > >> > >> The FreeBSD ports is already extremely complicated, do not make it > >> even harder :( > > The suggestion is not for ports, but for packages.. > > a single package could be unpacked in 'runtime only' or 'everything' > > mode. > > basically one package, two manifests. So no "foo-devel" or "foo-runtime" > > just 'foo' > > It is for ports, because packages are built using ports, and ports would > need to grow the feature. > It is imho doable in both sides. We could imagine tagging the plist/manifest so pkg can allow a user to install only the things tagged as runtime for exemple which would do the job. for what Julian is asking for beside adding lots of complexity pkg(8) and adding a nightmare in the solver. That would "please" the people that want "hey keep the giant flat package as it is better for dev given I don't have to install the -devel version something" and the people wanting fine grain selection if they need to. But on the ports side that would be a nightmare having to tag all the plist (and this cannot be automated because there are to many corner cases. Having the port that grows the feature would be really nice because no work would be needed on pkg :) and that would reduce cluster package building as we could merge qt, php etc into one port that builds multiple sub packages. Best regards, Bapt signature.asc Description: PGP signature
www/magento port outdated
hello, i would like to ask if it is possible to update the port www/magento to its current version. it is currently on version 1.8.1 which is more than 2 years old. the most recent version would be 2.1.2 or 2.0.10 according to https://www.magentocommerce.com/download kind regards, Alexander Liebau ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gcc5 dependency challenges
On 14/10/2016 12:48 AM, Dewayne Geraghty wrote: After some rudimentary performance testing I note that we get up around 3% improvement in application performance when we use gcc5 for our package builds. However building ports with gcc results in gcc5 being a dependency. Examining ldd, we find that rarely does anything require gcc5's shared libs for their execution. Even simple things like ftp/wget and devel/ccache depend on gcc5 for building but NOT runtime. As we aren't allowed to install compilers onto production systems, what is the best course of action to address? (We could just install gcc5 and then remove it but then of course, the base pkg wants to remove everything (600+ packages) that depends on gcc5!) So the question is - how should we build our packages or install them so that gcc5 is not (unnecessarily) installed? This is a topic I have been discussing in this list over the last few weeks. My understanding is that the compiler should not be a dependency for the package. I have been suggesting that packages should be installable in two manners, runtime or developement. In runtie mode they would only unpack the binary results (and not the man pages or .a files or .h files) and would only give library dependancies as depends.. In devel mode they woudl be sort of like now.. We've added to our /etc/make.conf USE_GCC= 5 but I wonder if there's something like a build_depends mechanism? Background: Our FreeBSD 10.3 Stable uses pkg 1.8.3; whereas ports uses 1.8.7_3, minor point. Why gcc5? Well most ports use clang 3.4.1 to compile, some ports do use gcc 4.8.5; and if we move to FreeBSD11 then we also need to add llvm3.6 into the build/migrating equation. So to aid our migration effort we "think" choosing gcc5 now is a good idea; particularly as /usr/ports/base/gcc uses gcc 5.4.0 (rather than /usr/ports/lang/gcc which is 4.8.5) All production systems use local package repositories (as heimdal is widely used as are non-default options). Kind regards, Dewayne ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
Le 14/10/2016 à 09:34, Julian Elischer a écrit : > On 13/10/2016 5:42 AM, David Demelier wrote: >> 2016-10-12 10:04 GMT+02:00 Andrea Venturoli : >>> On 10/12/16 09:24, Matthieu Volat wrote: >>> And GNU/Linuxes can be a PITA when you have to track -dev(el) packages (which sometimes really requires -bin, -app or whatever), or worst, describe to people how they are supposed to build your software with weird subpackage names. I really like that ports provides the software project as intended by upstream (modulo options). >>> >>> Just a "me too" here! >> Could not agree more. >> >> Please forget that idea. >> >> I just hate having to install libfoo, libfoo-dev, libfoo-dbg, >> libfoo-doc, libfoo-whatever each time I need to develop on Linux. >> Please do not transform FreeBSD as a Linux distribution :) >> >> I love the way FreeBSD and some very sparse Linux distributions >> provide the packages exactly how it would be installed by hand (= >> vanilla). >> >> FreeBSD offers some options and very few changes for better >> integration but packages are provided vanilla. You want a package? You >> install /packagename/ nothing more, nothing less. I really would like >> to see simple vanilla packages for the next 10 years. >> >> The FreeBSD ports is already extremely complicated, do not make it >> even harder :( > The suggestion is not for ports, but for packages.. > a single package could be unpacked in 'runtime only' or 'everything' > mode. > basically one package, two manifests. So no "foo-devel" or "foo-runtime" > just 'foo' It is for ports, because packages are built using ports, and ports would need to grow the feature. -- Mathieu Arnold signature.asc Description: OpenPGP digital signature
gcc5 dependency challenges
After some rudimentary performance testing I note that we get up around 3% improvement in application performance when we use gcc5 for our package builds. However building ports with gcc results in gcc5 being a dependency. Examining ldd, we find that rarely does anything require gcc5's shared libs for their execution. Even simple things like ftp/wget and devel/ccache depend on gcc5 for building but NOT runtime. As we aren't allowed to install compilers onto production systems, what is the best course of action to address? (We could just install gcc5 and then remove it but then of course, the base pkg wants to remove everything (600+ packages) that depends on gcc5!) So the question is - how should we build our packages or install them so that gcc5 is not (unnecessarily) installed? We've added to our /etc/make.conf USE_GCC= 5 but I wonder if there's something like a build_depends mechanism? Background: Our FreeBSD 10.3 Stable uses pkg 1.8.3; whereas ports uses 1.8.7_3, minor point. Why gcc5? Well most ports use clang 3.4.1 to compile, some ports do use gcc 4.8.5; and if we move to FreeBSD11 then we also need to add llvm3.6 into the build/migrating equation. So to aid our migration effort we "think" choosing gcc5 now is a good idea; particularly as /usr/ports/base/gcc uses gcc 5.4.0 (rather than /usr/ports/lang/gcc which is 4.8.5) All production systems use local package repositories (as heimdal is widely used as are non-default options). Kind regards, Dewayne ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
On 13/10/2016 10:33 AM, RW via freebsd-ports wrote: On Tue, 11 Oct 2016 11:59:47 -0700 Julian Elischer wrote: As the number of dependencies between packages get ever higher, it becomes more and more difficult to compile packages and the dependence on binary precompiled packages is increased. However binary packages are unsuitable for some situations. We really need to follow the lead of some of the Linux groups and have -runtime and -devel versions of packages, OR we what woudlbe smarter, woudl be to have several "sub manifests" to allow unpacking in different environments. A simple example: libxml2 This package installs include files and libraries and dicumentation etc. yet if I build an appliance , I want it to only install a singe file. /usr/local/lib/libxml2.so.2 What practical problem does installing the include files and man pages cause you? I have to delete them from the appliance I'm building up. So I need to get the manifest, remove the files I want from it, and delete every other file mentioned. This is an appliance class machine. It has 2G of storage and that has to include 2 copies for the OS so we can ping-pong for upgrades. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
On 13/10/2016 5:42 AM, David Demelier wrote: 2016-10-12 10:04 GMT+02:00 Andrea Venturoli : On 10/12/16 09:24, Matthieu Volat wrote: And GNU/Linuxes can be a PITA when you have to track -dev(el) packages (which sometimes really requires -bin, -app or whatever), or worst, describe to people how they are supposed to build your software with weird subpackage names. I really like that ports provides the software project as intended by upstream (modulo options). Just a "me too" here! Could not agree more. Please forget that idea. I just hate having to install libfoo, libfoo-dev, libfoo-dbg, libfoo-doc, libfoo-whatever each time I need to develop on Linux. Please do not transform FreeBSD as a Linux distribution :) I love the way FreeBSD and some very sparse Linux distributions provide the packages exactly how it would be installed by hand (= vanilla). FreeBSD offers some options and very few changes for better integration but packages are provided vanilla. You want a package? You install /packagename/ nothing more, nothing less. I really would like to see simple vanilla packages for the next 10 years. The FreeBSD ports is already extremely complicated, do not make it even harder :( The suggestion is not for ports, but for packages.. a single package could be unpacked in 'runtime only' or 'everything' mode. basically one package, two manifests. So no "foo-devel" or "foo-runtime" just 'foo' Regards, ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
2016-10-14 8:14 GMT+02:00 Loïc BLOT : > FreeBSD ports are complicated ? > Does someone of you tryed to do a Debian package, it's even more > complicated as you should modify many path, split package in multiple > packages, do the service engineering with systemV or systemD, etc ? It's not writing a port that is complicated, it's the whole infrastructure. -- Demelier David ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"