Re: Port system "problems"
Baptiste Daroussin : On Tue, Jun 26, 2012 at 12:22:28AM +0200, Florent Peterschmitt wrote: Hello, I'm not a developer and I know how it's difficult to make a port (or some ports, for example VirtualBox) but I think the port system has many "problems": 1. Ports are not modular What do you mean by modular? if you are speaking about subpackages it is coming, but it takes time I hope, we are not talking about some Debian-like approach here (foo-bin, foo-dev, foo-doc, ). 2. Option system is not really well documented What kind of documentation do you need?, please report what you are expected so that we can improve it 3. Some dependencies are totally useless Please report PR 4. So slow... What is slow do you mean compiling is slow? Let me give some examples: 1. games/wesnoth should be splitted in games/wesnoth-bin and games/wesnoth-datas. Why rebuild everything when just binaries needs ? This is coming, it takes lot of time, and some things have to be done first, in the infrastructure that the user do not see much. I do not see any necessity for infrastructure changes here - we did that in the past for several ports (e.g. alephone, alienarena, ...). 2. Why do we have to put WITH_NEW_XORG in /etc/make.conf to get it ? Why not put this var in a port configuration file which will be read by all ports needing this var ? Because this is not that easy, do you have a technical way to propose? I think noone is really happy with the WITH_NEW_XORG, but this is the "less worse" :) way we found, if you have a better way to propose, please step up and propose. /etc/make.conf (or whatever to be included in /etc/make.conf) can be seen as port configuration file that is evaluated by the ports. And each port picks those things, it needs. Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On 26/06/2012 08:26, Marcus von Appen wrote: >>> 1. Ports are not modular >> What do you mean by modular? if you are speaking about subpackages it >> is coming, >> but it takes time > I hope, we are not talking about some Debian-like approach here (foo-bin, > foo-dev, foo-doc, ). Actually, yes -- that's pretty much exactly what we're talking about here. Why do you feel subpackages would be a bad thing? Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Port system "problems"
Snippets from Jeremy Messenger ^ and Florent Peterschmitt > : > 2. Why do we have to put WITH_NEW_XORG in /etc/make.conf to get it ? Why not > put this var in a port configuration file which will be read by all ports > needing this var ? ^ I am trying to figure out why it's hard to put the WITH_NEW_XORG in make.conf. > 3. Why does GNOME really needs x11/yelp which depends on www/libxul, which > is a big port to build ? I don't need yelp and I'm sure not to be alone > don't need this. ^ The GNOME does need yelp when you go to the 'Help' menu. If I remove ^ the yelp then we WILL get a whine from you about that GNOME is broke ^ because the 'Help' menu doesn't work. I was going to put WITH_NEW_XORG=YES in /etc/make.conf . Is that correct syntax? I was bitten by lack of yelp last April when running Gnumeric for income tax calculations: help didn't work. It ought to be a dependency in gnumeric or goffice, or at least optional. Tom ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On 06/26/12 09:58, Matthew Seaman wrote: On 26/06/2012 08:26, Marcus von Appen wrote: 1. Ports are not modular What do you mean by modular? if you are speaking about subpackages it is coming, but it takes time I hope, we are not talking about some Debian-like approach here (foo-bin, foo-dev, foo-doc, ). Actually, yes -- that's pretty much exactly what we're talking about here. Why do you feel subpackages would be a bad thing? Can I share my 2c? Because it will just multiply be three the number of ports each of us has to install/maintain/upgrade/etc... bye av. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
Matthew Seaman : On 26/06/2012 08:26, Marcus von Appen wrote: 1. Ports are not modular What do you mean by modular? if you are speaking about subpackages it is coming, but it takes time I hope, we are not talking about some Debian-like approach here (foo-bin, foo-dev, foo-doc, ). Actually, yes -- that's pretty much exactly what we're talking about here. Why do you feel subpackages would be a bad thing? Because it makes installing ports more complex, causes maintainers to rip upstream installation routines apart, and burdens users with additional tasks to perform for what particular benefit (except saving some disk space)? If I want to do some development the Debian way, I would need to do the following: - install foo-bin (if it ships with binaries) - install foo-lib (libraries, etc.) - install foo-dev (headers, etc.) - install foo-doc (API docs) With the ports I am currently doing: - install foo What are the requirements, use cases and benefits for splitting up packages in such a way? How would it work with the ports infrastructure without making things more complex for port maintainers and the different port installation scenarios, we have? Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On Tue, Jun 26, 2012 at 09:26:45AM +0200, Marcus von Appen wrote: > > Baptiste Daroussin : > > > On Tue, Jun 26, 2012 at 12:22:28AM +0200, Florent Peterschmitt wrote: > >> Hello, > >> > >> I'm not a developer and I know how it's difficult to make a port (or > >> some ports, for example VirtualBox) but I think the port system has many > >> "problems": > >> > >> 1. Ports are not modular > > What do you mean by modular? if you are speaking about subpackages > > it is coming, > > but it takes time > > I hope, we are not talking about some Debian-like approach here (foo-bin, > foo-dev, foo-doc, ). I'm just talking about giving the ability to split packages :) after that we can imagine our own way. > > >> 2. Option system is not really well documented > > What kind of documentation do you need?, please report what you are > > expected so > > that we can improve it > > > >> 3. Some dependencies are totally useless > > Please report PR > > > >> 4. So slow... > > What is slow do you mean compiling is slow? > > > >> > >> Let me give some examples: > >> > >> 1. games/wesnoth should be splitted in games/wesnoth-bin and > >> games/wesnoth-datas. Why rebuild everything when just binaries needs ? > > > > This is coming, it takes lot of time, and some things have to be > > done first, in > > the infrastructure that the user do not see much. > > I do not see any necessity for infrastructure changes here - we did that > in the past for several ports (e.g. alephone, alienarena, ...). No be able to have sub packages and flavours (aka N packages from one port) there are changes needed > > >> 2. Why do we have to put WITH_NEW_XORG in /etc/make.conf to get it ? Why > >> not put this var in a port configuration file which will be read by all > >> ports needing this var ? > > > > Because this is not that easy, do you have a technical way to > > propose? I think > > noone is really happy with the WITH_NEW_XORG, but this is the "less worse" > > :) > > way we found, if you have a better way to propose, please step up > > and propose. > > /etc/make.conf (or whatever to be included in /etc/make.conf) can be > seen as port > configuration file that is evaluated by the ports. And each port picks > those things, > it needs. > +1 regards, Bapt pgpjSA3LvOGeh.pgp Description: PGP signature
Re: Port system "problems"
On Tue, Jun 26, 2012 at 10:34:00AM +0200, Marcus von Appen wrote: > Matthew Seaman : > > > On 26/06/2012 08:26, Marcus von Appen wrote: > 1. Ports are not modular > > > >>> What do you mean by modular? if you are speaking about subpackages it > >>> is coming, > >>> but it takes time > > > >> I hope, we are not talking about some Debian-like approach here (foo-bin, > >> foo-dev, foo-doc, ). > > > > Actually, yes -- that's pretty much exactly what we're talking about > > here. Why do you feel subpackages would be a bad thing? > > Because it makes installing ports more complex, causes maintainers to rip > upstream installation routines apart, and burdens users with additional tasks > to perform for what particular benefit (except saving some disk space)? > > If I want to do some development the Debian way, I would need to do the > following: > > - install foo-bin (if it ships with binaries) > - install foo-lib (libraries, etc.) > - install foo-dev (headers, etc.) > - install foo-doc (API docs) > > With the ports I am currently doing: > > - install foo > yes but you do not allow to install 2 packages one depending on mysql51 and one depending on mysql55, there will be conflicts on dependency just because of developpement files, the runtime can be made not to conflict. I trust maintainers to no abuse package splitting and do it when it make sense. In the case you give I would probably split the package that way: foo (everything needed in runtime: bin + libraries) foo-dev (everything needed for developper: headers, static libraries, pkg-config stuff, libtool stuff, API docs) foo-docs (all user documentation about the runtime) of course there will be no rule on how to split packages, just common sense. regards, Bapt pgpmJ8yull6vD.pgp Description: PGP signature
Re: Port system "problems"
On Tue, Jun 26, 2012 at 10:17:12AM +0200, Andrea Venturoli wrote: > On 06/26/12 09:58, Matthew Seaman wrote: > > On 26/06/2012 08:26, Marcus von Appen wrote: > 1. Ports are not modular > > > >>> What do you mean by modular? if you are speaking about subpackages it > >>> is coming, > >>> but it takes time > > > >> I hope, we are not talking about some Debian-like approach here (foo-bin, > >> foo-dev, foo-doc, ). > > > > Actually, yes -- that's pretty much exactly what we're talking about > > here. Why do you feel subpackages would be a bad thing? > > Can I share my 2c? > > Because it will just multiply be three the number of ports each of us > has to install/maintain/upgrade/etc... > Not at all for a maintainer it will be the same has having multiple options, because it will remain 1 port -> N packages Most of the time the ports are already splitted in slave ports (samba, *sql*, ldap etc), having them in a single port will simplify life of lots of maintainers, and simplify the port code regards, Bapt pgpyGdrSnpLYT.pgp Description: PGP signature
Re: Port system "problems"
Baptiste Daroussin : On Tue, Jun 26, 2012 at 10:34:00AM +0200, Marcus von Appen wrote: Matthew Seaman : > On 26/06/2012 08:26, Marcus von Appen wrote: 1. Ports are not modular > >>> What do you mean by modular? if you are speaking about subpackages it >>> is coming, >>> but it takes time > >> I hope, we are not talking about some Debian-like approach here (foo-bin, >> foo-dev, foo-doc, ). > > Actually, yes -- that's pretty much exactly what we're talking about > here. Why do you feel subpackages would be a bad thing? Because it makes installing ports more complex, causes maintainers to rip upstream installation routines apart, and burdens users with additional tasks to perform for what particular benefit (except saving some disk space)? If I want to do some development the Debian way, I would need to do the following: - install foo-bin (if it ships with binaries) - install foo-lib (libraries, etc.) - install foo-dev (headers, etc.) - install foo-doc (API docs) With the ports I am currently doing: - install foo yes but you do not allow to install 2 packages one depending on mysql51 and one depending on mysql55, there will be conflicts on dependency just because of developpement files, the runtime can be made not to conflict. But I can't install mysql51-dev and mysql55-dev. Resolving those conflicts by e.g. introducing unique prefixes would be much better. Shouldn't we rather find a solid concept for avoiding CONFLICT entries by using e.g. improved prefixes, instead of starting to split packages, which does not add any noticeable benefit (at least I can't see one yet). I trust maintainers to no abuse package splitting and do it when it make sense. In the case you give I would probably split the package that way: foo (everything needed in runtime: bin + libraries) If the libs of e.g. mysql51 and mysql55 are named similar, we still have the same problem as mentioned above and end up with additionaly hackery, which better would be placed elsewhere. foo-dev (everything needed for developper: headers, static libraries, pkg-config stuff, libtool stuff, API docs) foo-docs (all user documentation about the runtime) For which version? 51, 55? Again, we need some prefix hackery to keep that clean and allow a side-by-side installation. Although I refer to your example, it is not limited to it. The same applies to other ports, which install multiple versions. I doubt, that splitting ports is the right way to go here, since it does not solve the initial problem. As long as there are CONFLICTs, splitting just tries to circumvent them. Instead we should handle them right from the start. We did it with some success (and still existing regressions) for e.g. lang/python. So we surely can take our time to edge out some guidelines and best practices for avoiding CONFLICTs. Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On 26/06/2012 09:17, Andrea Venturoli wrote:
> On 06/26/12 09:58, Matthew Seaman wrote:
>> On 26/06/2012 08:26, Marcus von Appen wrote:
> 1. Ports are not modular
>>
What do you mean by modular? if you are speaking about subpackages it
is coming,
but it takes time
>>
>>> I hope, we are not talking about some Debian-like approach here
>>> (foo-bin,
>>> foo-dev, foo-doc, ).
>>
>> Actually, yes -- that's pretty much exactly what we're talking about
>> here. Why do you feel subpackages would be a bad thing?
>
> Can I share my 2c?
>
> Because it will just multiply be three the number of ports each of us
> has to install/maintain/upgrade/etc...
Yes, it will multiply the number of ports. By three is about right,
given that most ports will only have port-docs and port-examples
sub-ports. However, first of all, you are assuming that the effort
required to install each of those sub-ports is the same as it is to
install a single port now. That is simply not the case.
If you want to install the foo/bar port, then (as now) you'ld
essentially[+] --
# cd ${PORTSDIR}/foo/bar
# make
# make install
but you'ld end up with bar-0.99, bar-doc-0.99 and bar-examples-0.99
installed. Unless you have a setting like NOPORTDOCS or NOPORTEXAMPLES
(probably controlled by a dialogue menu like any other options) which
means you don't get the associated -docs or -examples sub-ports.
That's no real change in terms of what you'ld have to do compared to now.
The difference is that if you install from packages, you now have the
opportunity not to install docs or examples.
Secondly, that's just one example of how sub-ports should work, and
docs/examples will be special-cased given their ubiquity. Most
sub-ports would be controlled by port OPTIONS dialogues.
A typical example would involve client-server apps -- so mysqlNN-server
becomes a sub-port of mysqlNN-client. You get to check a box saying
'install the server as well as the client' when you go to install
mysqlNN. Similarly all those php5-XYZ modules become sub-ports of
lang/php5. The big difference being that the port and all its sub-ports
are compiled in one step, and just packaged separately. Which is
probably less work overall that the current situation with ports and
slave-ports.
Cheers,
Matthew
[+] Or more likely you'ld use portupgrade or portmaster or similar to
run these steps for you.
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
Re: Port system "problems"
On 06/26/12 11:03, Matthew Seaman wrote: Yes, it will multiply the number of ports. By three is about right, given that most ports will only have port-docs and port-examples sub-ports. However, first of all, you are assuming that the effort required to install each of those sub-ports is the same as it is to install a single port now. That is simply not the case. Not exactly. I still didn't get the details, so I might speak nonsense, however... The "effort" will be 3x processing time for portupgrade (or whatever) to update the package database 3 times as much as before. I remember the big X.org split up: going from a few ports to tens of them slowed down an installation/upgrade process by an order of magnitude (or even more). A typical example would involve client-server apps -- so mysqlNN-server becomes a sub-port of mysqlNN-client. You get to check a box saying 'install the server as well as the client' when you go to install mysqlNN. Similarly all those php5-XYZ modules become sub-ports of lang/php5. We had this in the past: a php-extension port with options to include each extension or leave it out. Each time we needed to add a missing extension, we needed to reconfigure this port and rebuild all. Now we have each extension in its own port and I think it's much better. I just hope we don't get back to that. What I anticipate will often happen is installing some port, finding out that some part is missing, install the missing part, repeat that several times. I just hope I'm wrong (and again, it is at all possible that I am wrong here). bye & Thanks av. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Linux software won't install were it's told to!
Disclosure: I have posted this question on the forums too. I am still attempting to port Quartus II design software to FreeBSD. I am making progress, with the help of this list and others. My latest problem is strange. I've followed all the shell script wrappers to find the actual installation binary that is run. It takes an option that lets the user specify where to install (-t ). When I run it thus: # altera_installer_cmd --source=/usr/ports/cad/quartus_ii/work --install=quartus_free -w -t /home/benjamin/some_dir --no_space_check It installs to some_dir in my home directory, as expected. If I change the install path to /usr/local however: # altera_installer_cmd --source=/usr/ports/cad/quartus_ii/work --install=quartus_free -w -t /usr/local/quartus --no_space_check (the only difference between the two commands is the "-t " bit) It somehow installs to /compat/linux/usr/local/quartus rather than /usr/local/quartus! It is almost as if there is a magic "symlink" redirecting certain folders, but it doesn't redirect when I specify my home directory. What could be going on here? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On 26.06.2012 11:03, Matthew Seaman wrote:
On 26/06/2012 09:17, Andrea Venturoli wrote:
On 06/26/12 09:58, Matthew Seaman wrote:
On 26/06/2012 08:26, Marcus von Appen wrote:
1. Ports are not modular
What do you mean by modular? if you are speaking about subpackages it
is coming,
but it takes time
I hope, we are not talking about some Debian-like approach here
(foo-bin,
foo-dev, foo-doc, ).
Actually, yes -- that's pretty much exactly what we're talking about
here. Why do you feel subpackages would be a bad thing?
Can I share my 2c?
Because it will just multiply be three the number of ports each of us
has to install/maintain/upgrade/etc...
Yes, it will multiply the number of ports. By three is about right,
given that most ports will only have port-docs and port-examples
sub-ports. However, first of all, you are assuming that the effort
required to install each of those sub-ports is the same as it is to
install a single port now. That is simply not the case.
If you want to install the foo/bar port, then (as now) you'ld
essentially[+] --
# cd ${PORTSDIR}/foo/bar
# make
# make install
but you'ld end up with bar-0.99, bar-doc-0.99 and bar-examples-0.99
installed. Unless you have a setting like NOPORTDOCS or NOPORTEXAMPLES
(probably controlled by a dialogue menu like any other options) which
means you don't get the associated -docs or -examples sub-ports.
That's no real change in terms of what you'ld have to do compared to now.
The difference is that if you install from packages, you now have the
opportunity not to install docs or examples.
Secondly, that's just one example of how sub-ports should work, and
docs/examples will be special-cased given their ubiquity. Most
sub-ports would be controlled by port OPTIONS dialogues.
A typical example would involve client-server apps -- so mysqlNN-server
becomes a sub-port of mysqlNN-client. You get to check a box saying
'install the server as well as the client' when you go to install
mysqlNN. Similarly all those php5-XYZ modules become sub-ports of
lang/php5. The big difference being that the port and all its sub-ports
are compiled in one step, and just packaged separately. Which is
probably less work overall that the current situation with ports and
slave-ports.
Cheers,
Matthew
[+] Or more likely you'ld use portupgrade or portmaster or similar to
run these steps for you.
Hello,
It's exactly what I wanted to say. I think so that port system should
adapt to this way of building ports. I mean that is instead of having
vala, we have vala-bin, vala-doc, vala-lib and vala-examples, and port
system don't untar vala archive for each port, but once and pick up
files into this unique directory. Then no waste of time because untar is
what takes most time for big ports.
We should still have a vala port, which is used to configure what we
want (other subports -examples, -lib and -doc).
But where it can be very useful, it's when we have a big port made of
many libraries, like Mono. We should be able to split it, because I
don't want to build everything.
For the GNOME question, if an option in the GNOME configuration port
says "[x] Yelp, will break help menus if not set", then no problem,
don't you think ?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On 26/06/2012 10:31, Andrea Venturoli wrote: > On 06/26/12 11:03, Matthew Seaman wrote: > >> Yes, it will multiply the number of ports. By three is about right, >> given that most ports will only have port-docs and port-examples >> sub-ports. However, first of all, you are assuming that the effort >> required to install each of those sub-ports is the same as it is to >> install a single port now. That is simply not the case. > > Not exactly. > I still didn't get the details, so I might speak nonsense, however... > > The "effort" will be 3x processing time for portupgrade (or whatever) to > update the package database 3 times as much as before. > I remember the big X.org split up: going from a few ports to tens of > them slowed down an installation/upgrade process by an order of > magnitude (or even more). The X.org split up is an extreme case -- it went from three or four ports to several hundred ports as I recall. Yes, that made a big difference, because they were all individual ports and all of the processing steps required to install a port had to be repeated for each of them. Sub-ports should be much more efficient, as there's a lot of the work involved in installing which is a one-time thing when installing port plus some collection of sub-ports. Also remember that this whole change is driven in part by the switch to pkgng, and that uses a completely different package database system to the current ports. I can't say for certain that it will be a lot faster, because as far as I know, no one has done a properly designed study of the difference in performance. However anecdotal evidence is that it does seem quite a lot faster. >> A typical example would involve client-server apps -- so mysqlNN-server >> becomes a sub-port of mysqlNN-client. You get to check a box saying >> 'install the server as well as the client' when you go to install >> mysqlNN. Similarly all those php5-XYZ modules become sub-ports of >> lang/php5. > > We had this in the past: a php-extension port with options to include > each extension or leave it out. > Each time we needed to add a missing extension, we needed to reconfigure > this port and rebuild all. > Now we have each extension in its own port and I think it's much better. > I just hope we don't get back to that. > > > > What I anticipate will often happen is installing some port, finding out > that some part is missing, install the missing part, repeat that several > times. > I just hope I'm wrong (and again, it is at all possible that I am wrong > here). Yes, you raise a valid point. Should you have to compile and maybe reinstall all of php5 just to add some extra modules? Clearly not. This isn't going to be a problem for people that use binary packages, because they can just download and install the extra module from the standard pkg repositories on the net. What about people that want to compile their own? They certainly should not be relegated to second-class citizens even in this bright new dawn of pkgng. Well, part of the answer is under development: http://wiki.freebsd.org/ports/StageDir With this, you can create packages without having to install them. You can equally well create sub-packages without having to install them. So, you might compile all of the php5 sub-packages, but only install some of them. The rest you keep stashed away somewhere, so that when you suddenly discover a pressing need to add php5-shiny to your existing collection of php-related bits, it's just a matter of 'pkg add php5-shiny'. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Port system "problems"
Matthew Seaman : On 26/06/2012 10:31, Andrea Venturoli wrote: On 06/26/12 11:03, Matthew Seaman wrote: Yes, it will multiply the number of ports. By three is about right, given that most ports will only have port-docs and port-examples sub-ports. However, first of all, you are assuming that the effort required to install each of those sub-ports is the same as it is to install a single port now. That is simply not the case. Not exactly. I still didn't get the details, so I might speak nonsense, however... The "effort" will be 3x processing time for portupgrade (or whatever) to update the package database 3 times as much as before. I remember the big X.org split up: going from a few ports to tens of them slowed down an installation/upgrade process by an order of magnitude (or even more). The X.org split up is an extreme case -- it went from three or four ports to several hundred ports as I recall. Yes, that made a big difference, because they were all individual ports and all of the processing steps required to install a port had to be repeated for each of them. Sub-ports should be much more efficient, as there's a lot of the work involved in installing which is a one-time thing when installing port plus some collection of sub-ports. How does that look like in detail? Are there any concepts on about how it is supposed to work, what the implications are, and so forth? Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Porting applications with "nice" installers
Hi, I found two applications I would like to port. Both are written in java (not a problem) and both provide a graphical installer. The latter raises a couple of questions: One of the applications asks during the installation if you want to install Community (free of use) or Enterprise (evaluation only) editions and I'm not sure how to specify the Community edition without using the installer. Executing the main .java file in the sources seems to assume it is the evaluation only copy. The other application, when executed always launches an update installer that downloads the latest java files in the user home directory. Write permissions for the execution directory seems to be necessary (hence the fact that the application installs into the user home by default). How can I proceed here? If I install the "application" under /usr/local then nobody can execute it to launch the update application because there are not write permissions and the application doesn't run. Creating a directory with write permissions for anyone is not acceptable for several reasons either. Any ports dealing with these situations that I can use as a reference? Thanks in advance. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On 26/06/2012 12:07, Marcus von Appen wrote:
>> Sub-ports should be much more efficient, as there's a lot of the work
>> involved in installing which is a one-time thing when installing port
>> plus some collection of sub-ports.
> How does that look like in detail? Are there any concepts on about
> how it is supposed to work, what the implications are, and so forth?
Please understand that a lot of this stuff exists only in various
people's heads and is subject to arbitrary change as ideas evolve.
Other parts are more-or-less documented; some is already under
development and may or may not require various degrees of revision in
the light of experience.
Anyhow: the various stages of building a port at the moment are well known:
1 options dialogue
2 fetch & verify distfiles (*)
3 extract (*)
4 patch (*)
5 configure (*)
6 compile
7 install (*)
8 post-install scripts
9 register in pkg DB
Not all ports require all those stages. The stages marked (*) can
involve resolving various dependencies by installing other ports --
although {FETCH,EXTRACT,PATCH}_DEPENDS are relatively rare, and it's
usually {BUILD,LIB}_DEPENDS before configuring and RUN_DEPENDS before
installation that take up most of the time.
You have to do each of these steps (where applicable) for each port you
install. There will be some time savings for installing several closely
related ports. For instance: where you have -client and -server slave
ports, you'll generally not have to download any extra distfiles
(although you would still compare all the checksums.) One of those ports
would be usually a BUILD_DEPENDS of the other, so a lot of the
dependency chasing should already be done.
What's different in the new scheme?
1 options dialogue
2 fetch & verify distfiles
3 extract
4 patch
5 configure
6 compile
7 install to staging directory tree ***
8 create packages, sub-packages ***
9 install packages and sub-packages as selected ***
where running post-install scripts is incorporated into stage 9. (This
also means post-install scripts only have to be implemented once, unlike
currently where you have to implement both a post-install Makefile
target and a post-install script for use with pkgs.)
Stages 1-6 are essentially the same as at the moment: they may differ in
detail due to amalgamating master- and slave-port options etc. but they
only need to happen *once* for the whole collection of port and
sub-ports. The same sort of dependency chasing will happen as currently.
Installing into a staging directory tree involves installing all the
executables, data, documentation and other files from the port
irrespective of what sub-port they might belong to. This bit is an
addition compared to the current ports. Again though, it's a
one-time-for-all step.
Creating packages in the new scheme (ie. assuming pkgng) is a matter of
tarring up selected files from the staging directory along with two
blobs of meta data -- the YAML file containing the runtime dependency
data, package plist, various scripts to be run on
installation/deinstallation and the checksums of all the files, plus
various other information; and an MTREE file for creating the directory
hierarchy to install into. It's comparable to the current 'fake-pkg'
target in bsd.ports.mk. This step is repeated for each of the different
sub-packages, packing up different selections of
the staging directory contents each time. You may well be creating more
{sub-,}packages here than you ultimately intend to install.
Finally, installing the selected package and sub-packages -- this will
be identical to installing pre-compiled packages downloaded from one of
the standard package repositories, and involves unpacking and verifying
the tarball contents, making any necessary directory structure, moving
the files into place, running any scripts as specified in the metadata
and updating the package DB -- now an actual relational database stored
in a single file: ${PKG_DBDIR}/local.sqlite
Whether the extra/different work done in stages 7, 8 and 9 will negate
the savings from only doing stages 1-6 once remains to be seen. My
prediction is that mostly you'ld come out ahead, but whether you do, and
by how much will vary significantly between individual ports.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
Re: Port system "problems"
On Tue, 26 Jun 2012 04:31:40 -0500, Andrea Venturoli wrote: The "effort" will be 3x processing time for portupgrade (or whatever) to update the package database 3 times as much as before. pkgng uses sqlite. Please provide proof that it is as slow or slower than our current package database is. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Porting applications with "nice" installers
On Tue, 26 Jun 2012 06:56:14 -0500, Fernando Apesteguía wrote: Any ports dealing with these situations that I can use as a reference? The Opera port uses its own installer. Unfortunately if we want to split PORTDOCS off we'll have to install all the files manually... Keep things like that in mind. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
Matthew Seaman : On 26/06/2012 12:07, Marcus von Appen wrote: Sub-ports should be much more efficient, as there's a lot of the work involved in installing which is a one-time thing when installing port plus some collection of sub-ports. How does that look like in detail? Are there any concepts on about how it is supposed to work, what the implications are, and so forth? Please understand that a lot of this stuff exists only in various people's heads and is subject to arbitrary change as ideas evolve. Other parts are more-or-less documented; some is already under development and may or may not require various degrees of revision in the light of experience. I understand that quite well, but I fear that we miss to document it in the long-term. When I started fiddling around with bsd.port.mk in my early days, it sometimes was a pain to figure out, why code XYZ is in there and at which point of time it is triggered for exactly what purpose. Yes, I could have bugged those, who know, but I'd rather see that written down somewhere, so others can start faster with less nagging (which includes me, too, as someone to get started with writing things down :-). Hence I would love to see some docs on the bigger things that are on the doorstep, so that learning and understanding the overall system is less time consuming. Plus, a documentation (draft) in e.g. the Wiki allows a broader feedback and sharing of ideas without moving back and forth in the mailing list history. [long exaplanation of how the system is supposed to work] From what I understand, the whole magic happens in step 7-9. The port builds as usual, installs itself in a fake root (stagedir) and packages are created based on the relative paths, PORTEXAMPLES/DOCS, ... entries or plist placeholders or whatever. The maintainers are - if I got that right - completely off the hook with modifying their ports to split them in some way or another, correct? Do you mind to put your explanation into the Wiki (maybe using the StageDir page, since this would better explain what the purpose of StageDir is)? Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
php53-extensions-1.6 doesn't work with OPTIONSng
Hi, I tried to install or update php53-extensions on few machines and I always found a same bug. My options are ignored and php53-extensions are installed with default set of extensions. It's because Makefile contains old OPTIONS style. For example - I have following settings saved from previous run of make config php53-extensions/# grep '_SET+' /var/db/ports/php53-extensions/options OPTIONS_FILE_SET+=BZ2 OPTIONS_FILE_SET+=FILTER OPTIONS_FILE_SET+=ICONV OPTIONS_FILE_SET+=JSON OPTIONS_FILE_SET+=POSIX OPTIONS_FILE_SET+=SESSION It is recognized as: php53-extensions/# make showconfig | grep '=on:' BZ2=on: bzip2 library support FILTER=on: input filter support ICONV=on: iconv support JSON=on: JavaScript Object Serialization support POSIX=on: POSIX-like functions SESSION=on: session support But installation ends with following extensions installed: php53-extensions/# pkg_info -E php\* php53-5.3.14 php53-bz2-5.3.14 php53-ctype-5.3.14 php53-dom-5.3.14 php53-extensions-1.6 php53-filter-5.3.14 php53-hash-5.3.14 php53-iconv-5.3.14 php53-json-5.3.14 php53-mbstring-5.3.14 php53-pdo-5.3.14 php53-pdo_sqlite-5.3.14 php53-phar-5.3.14 php53-posix-5.3.14 php53-session-5.3.14 php53-simplexml-5.3.14 php53-sqlite-5.3.14 php53-sqlite3-5.3.14 php53-tokenizer-5.3.14 php53-xml-5.3.14 php53-xmlreader-5.3.14 php53-xmlwriter-5.3.14 And `make` is checking for those default extensions: php53-extensions/# make ===> License check disabled, port has not defined LICENSE ===> Found saved configuration for php53-extensions-1.6 ===> Extracting for php53-extensions-1.6 ===> Patching for php53-extensions-1.6 ===> php53-extensions-1.6 depends on file: /usr/local/include/php/main/php.h - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/bz2.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/ctype.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/dom.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/filter.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/hash.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/iconv.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/json.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/pdo.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/pdo_sqlite.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/phar.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/posix.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/session.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/simplexml.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/sqlite.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/sqlite3.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/tokenizer.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/xml.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/xmlreader.so - found ===> php53-extensions-1.6 depends on file: /usr/local/lib/php/20090626/xmlwriter.so - found ===> Configuring for php53-extensions-1.6 So the port lang/php53-extensions needs to be converted to OPTIONSng as lang/php5-extensions was. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On Tue, 26 Jun 2012 13:31:01 +0100 Matthew Seaman wrote: > What's different in the new scheme? > > 1 options dialogue > 2 fetch & verify distfiles > 3 extract > 4 patch > 5 configure > 6 compile > 7 install to staging directory tree *** > 8 create packages, sub-packages *** > 9 install packages and sub-packages as selected *** > Whether the extra/different work done in stages 7, 8 and 9 will negate > the savings from only doing stages 1-6 once remains to be seen. My > prediction is that mostly you'ld come out ahead, but whether you do, > and by how much will vary significantly between individual ports. It's not really worth looking at individual ports. It's the average on major updates that really matters. In my experience most of he time is spent building, and I just don't think that there all that much to be gained in the compile stage. The staging area is appealing in its own right. I'm less keen on sub-packages which are going to break update tools. I think it's very likely that only portmaster would survive. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On Tue, Jun 26, 2012 at 3:44 AM, Baptiste Daroussin wrote: > On Tue, Jun 26, 2012 at 10:34:00AM +0200, Marcus von Appen wrote: >> Matthew Seaman : >> >> > On 26/06/2012 08:26, Marcus von Appen wrote: >> 1. Ports are not modular >> > >> >>> What do you mean by modular? if you are speaking about subpackages it >> >>> is coming, >> >>> but it takes time >> > >> >> I hope, we are not talking about some Debian-like approach here (foo-bin, >> >> foo-dev, foo-doc, ). >> > >> > Actually, yes -- that's pretty much exactly what we're talking about >> > here. Why do you feel subpackages would be a bad thing? >> >> Because it makes installing ports more complex, causes maintainers to rip >> upstream installation routines apart, and burdens users with additional tasks >> to perform for what particular benefit (except saving some disk space)? >> >> If I want to do some development the Debian way, I would need to do the >> following: >> >> - install foo-bin (if it ships with binaries) >> - install foo-lib (libraries, etc.) >> - install foo-dev (headers, etc.) >> - install foo-doc (API docs) >> >> With the ports I am currently doing: >> >> - install foo I agree. > yes but you do not allow to install 2 packages one depending on mysql51 and > one > depending on mysql55, there will be conflicts on dependency just because of > developpement files, the runtime can be made not to conflict. > > I trust maintainers to no abuse package splitting and do it when it make > sense. > > In the case you give I would probably split the package that way: > foo (everything needed in runtime: bin + libraries) > foo-dev (everything needed for developper: headers, static libraries, > pkg-config > stuff, libtool stuff, API docs) > foo-docs (all user documentation about the runtime) > > of course there will be no rule on how to split packages, just common sense. Disagree. We shouldn't split for that. Have you seen how many Linux users report when they can't compile one of application, just because they didn't install the *-dev? A LOT (thousands and thousands)! When it's A LOT then it means that it's flawed. If the upstream provide the split tarballs then I do not have any problem with it. Also, it will slow down the ports tree pretty bad if we do that way to all ports. > regards, > Bapt -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On Tue, Jun 26, 2012 at 5:22 AM, Florent Peterschmitt wrote: > For the GNOME question, if an option in the GNOME configuration port says > "[x] Yelp, will break help menus if not set", then no problem, don't you > think ? It doesn't make any sense to do that. KDE and GNOME are a bloat desktop, and always will be. The Yelp has been part of GNOME for many years. -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On 06/26/12 12:42, Matthew Seaman wrote: What I anticipate will often happen is installing some port, finding out that some part is missing, install the missing part, repeat that several times. I just hope I'm wrong (and again, it is at all possible that I am wrong here). Yes, you raise a valid point. Should you have to compile and maybe reinstall all of php5 just to add some extra modules? Clearly not. This isn't going to be a problem for people that use binary packages, because they can just download and install the extra module from the standard pkg repositories on the net. What about people that want to compile their own? They certainly should not be relegated to second-class citizens even in this bright new dawn of pkgng. Well, part of the answer is under development: http://wiki.freebsd.org/ports/StageDir With this, you can create packages without having to install them. You can equally well create sub-packages without having to install them. So, you might compile all of the php5 sub-packages, but only install some of them. The rest you keep stashed away somewhere, so that when you suddenly discover a pressing need to add php5-shiny to your existing collection of php-related bits, it's just a matter of 'pkg add php5-shiny'. I'm not sure I undestood correctly (from this and other posts); please correct me if I'm wrong: _ the whole thing is aimed at packages; I won't be able to install ports directly, but I'll get an intermediate step that creates packages automatically; _ in the PHP example, I will create lots of subpackages, but I will eventually install only some; _ I can keep the packages somewhere, so I can install them later. Well, if I'm correct, the above will be a no go for me: lots of my customer's servers are tight on disk space and they won't spend for new storage. So this will mean I won't be able to use ports anymore and I'll need to download packages directly? bye & Thanks av. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On 06/26/12 17:20, RW wrote: In my experience most of he time is spent building This is not necessarily true. Try X.Org (with all its very small ports) or MIMEDefang (depending on gobs of p5- ports) or anything else alike. You'll find out a good share of the total time is spent maintaining pkgdb and other administrativia. bye av. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Linux software won't install were it's told to!
On Tue, Jun 26, 2012 at 4:47 AM, Benjamin wrote: > Disclosure: I have posted this question on the forums too. > > I am still attempting to port Quartus II design software to FreeBSD. I am > making progress, with the help of this list and others. > > My latest problem is strange. I've followed all the shell script wrappers to > find the actual installation binary that is run. It takes an option that > lets the user specify where to install (-t ). > > When I run it thus: > > # altera_installer_cmd --source=/usr/ports/cad/quartus_ii/work > --install=quartus_free -w -t /home/benjamin/some_dir --no_space_check > > It installs to some_dir in my home directory, as expected. If I change the > install path to /usr/local however: > > # altera_installer_cmd --source=/usr/ports/cad/quartus_ii/work > --install=quartus_free -w -t /usr/local/quartus --no_space_check > > (the only difference between the two commands is the "-t " bit) > > It somehow installs to /compat/linux/usr/local/quartus rather than > /usr/local/quartus! It is almost as if there is a magic "symlink" > redirecting certain folders, but it doesn't redirect when I specify my home > directory. > > What could be going on here? > This is being caused by the linux emulation where it adds the prefix '/compat/linux' to the specified path. linux_emul_path - http://fxr.watson.org/fxr/source/compat/linux/linux_util.c?im=bigexcerpts#L64 linux_emul_convpath - http://fxr.watson.org/fxr/source/compat/linux/linux_util.c?im=bigexcerpts#L98 kern_alternate_path - http://fxr.watson.org/fxr/source/kern/vfs_lookup.c?im=10#L1158 If you create the directory '/usr/local/quartus' first, will it install to this location? Scot ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On 06/26/12 16:34, Mark Felder wrote: On Tue, 26 Jun 2012 04:31:40 -0500, Andrea Venturoli wrote: The "effort" will be 3x processing time for portupgrade (or whatever) to update the package database 3 times as much as before. pkgng uses sqlite. Please provide proof that it is as slow or slower than our current package database is. I cannot. However I don't think that's the point. A faster DB system with 3X records might perform better or worse than current DB system with X records; even if the balance was positive, it would still be slower than the new DB system with X records. That is still a reason against splitting in the wild. bye av. P.S. I'd gladly try sqlite instead of the current pkgdb and see: is it possible to switch without any side-effect or complication? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On 26/06/2012 17:00, Andrea Venturoli wrote: > I'm not sure I undestood correctly (from this and other posts); please > correct me if I'm wrong: > _ the whole thing is aimed at packages; I won't be able to install ports > directly, but I'll get an intermediate step that creates packages > automatically; > _ in the PHP example, I will create lots of subpackages, but I will > eventually install only some; > _ I can keep the packages somewhere, so I can install them later. Yes: essentially, the ports tree is used to build packages and those packages are what are installed. OpenBSD ports has worked this way for many years. > Well, if I'm correct, the above will be a no go for me: lots of my > customer's servers are tight on disk space and they won't spend for new > storage. So this will mean I won't be able to use ports anymore and I'll > need to download packages directly? If you have many systems to maintain, then pkgng should help by making it much easier for you to create an off-line package building system and associated repository. You won't necessarily have to have a ports tree on your customer systems at all, and you won't need to take up space on your customer systems installing any build dependencies there. Both poudriere and tinderbox-devel support creating pkgng package repositories, if you want a management system for your build-box. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Port system "problems"
On 26/06/2012 16:20, RW wrote: > The staging area is appealing in its own right. I'm less keen > on sub-packages which are going to break update tools. I think it's > very likely that only portmaster would survive. Yes -- omlettes, eggs etc. There will be some inevitable disruption in the ports tree to get all these changes in place. However, I hope people will agree that the end result is worth it. Staging will be (at least at first) a soft introduction. That is, patches should go into bsd.ports.mk et al to add staging capability to the ports tree generally, but nothing will change for an individual port until the maintainer adds 'USE_STAGE=yes'. In this way, we can test out some specimen ports thoroughly in live usage, debug the inevitable problems and work out the best practices for a maintainer to do the switchover on their ports. Then we have a campaign to switch individual ports over to staging, much like the ongoing OPTIONSng conversion. This, we believe, should cause minimal impact to end-users. Eventually 'USE_STAGE=yes' will be made the default and required for all new ports. Any remaining unconverted ports will have to have 'USE_STAGE=no.' Introducing sub-ports would be done in a similar gradual manner, but plans for that are still quite vapourous. I don't share your pessimism over the fate of all the port updating tools -- if we do this right, there should be sufficient time and volunteers making patches to get everything fixed up. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Port system "problems"
On 26 June 2012 16:20, RW wrote: > On Tue, 26 Jun 2012 13:31:01 +0100 > Matthew Seaman wrote: > > >> What's different in the new scheme? >> >> 1 options dialogue >> 2 fetch & verify distfiles >> 3 extract >> 4 patch >> 5 configure >> 6 compile >> 7 install to staging directory tree *** >> 8 create packages, sub-packages *** >> 9 install packages and sub-packages as selected *** > > > >> Whether the extra/different work done in stages 7, 8 and 9 will negate >> the savings from only doing stages 1-6 once remains to be seen. My >> prediction is that mostly you'ld come out ahead, but whether you do, >> and by how much will vary significantly between individual ports. > > It's not really worth looking at individual ports. It's the average on > major updates that really matters. In my experience most of he time > is spent building, and I just don't think that there all that much to be > gained in the compile stage. > > The staging area is appealing in its own right. I'm less keen > on sub-packages which are going to break update tools. I think it's > very likely that only portmaster would survive. Nah, the new maintainer for portupgrade is heavily involved in development, and is actually now a pkgng developer. Also, with pkgng the emphasis is more on binary upgrades. We really shouldn't still be compiling from source for everything in this day and age-- we're one of only two major projects that still do this as the main upgrade solution. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On 26/06/2012 17:17, Andrea Venturoli wrote: > I'd gladly try sqlite instead of the current pkgdb and see: is it > possible to switch without any side-effect or complication? Just install ports-mgmt/pkg and follow the instructions. At the moment the change is effectively to give you the new /var/db/pkg/local.sqlite package DB without the rest of the ports functioning appreciably differently. Note: while there is an automated method for converting old pkg_tools -> pkgng, there isn't an easy way to do the reverse. Take backups, don't do this on any really important systems just yet, yadda yadda. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: xfce 10 and icons
Hi, just that it does not get lost. This is the whole difference I observed: diff -rN config-old/.config/xfce4/xfconf/xfce-perchannel-xml/xsettings.xml .config/xfce4/xfconf/xfce-perchannel-xml/xsettings.xml 6c6 < --- > By the way, after the switching back and forth, two icons are still missing: Multimedia/Mixer and Settings/Keyboard. Not a big deal of course. Thanks again Riggs ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: xfce 10 and icons
2012/6/26 Thomas Zander : > Hi, > > just that it does not get lost. This is the whole difference I observed: > > diff -rN config-old/.config/xfce4/xfconf/xfce-perchannel-xml/xsettings.xml > .config/xfce4/xfconf/xfce-perchannel-xml/xsettings.xml > 6c6 > < > --- >> > You've found the patch ;) > By the way, after the switching back and forth, two icons are still > missing: Multimedia/Mixer and Settings/Keyboard. > Not a big deal of course. You must add misc/gnome-icon-theme. > > Thanks again > Riggs > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -- olivier ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: php53-extensions-1.6 doesn't work with OPTIONSng
Miroslav Lachman wrote:
Hi,
I tried to install or update php53-extensions on few machines and I
always found a same bug.
My options are ignored and php53-extensions are installed with default
set of extensions.
It's because Makefile contains old OPTIONS style.
[...]
So the port lang/php53-extensions needs to be converted to OPTIONSng as
lang/php5-extensions was.
I tried the attached patch and it works for me.
Miroslav Lachman
--- Makefile.orig 2012-05-16 11:46:45.0 +0200
+++ Makefile2012-06-26 19:02:22.0 +0200
@@ -24,86 +24,7 @@
LATEST_LINK= ${PORTNAME}${PKGNAMESUFFIX}
-WITH_CTYPE=yes
-WITH_DOM= yes
-WITH_FILTER= yes
-WITH_HASH= yes
-WITH_ICONV=yes
-WITH_JSON= yes
-WITH_PDO= yes
-WITH_PDO_SQLITE=yes
-WITH_PHAR= yes
-WITH_POSIX=yes
-WITH_SESSION= yes
-WITH_SIMPLEXML=yes
-WITH_SQLITE= yes
-WITH_SQLITE3= yes
-WITH_TOKENIZER=yes
-WITH_XML= yes
-WITH_XMLREADER=yes
-WITH_XMLWRITER=yes
-
-OPTIONS= BCMATH "bc style precision math functions" off \
- BZ2 "bzip2 library support" off \
- CALENDAR"calendar conversion support" off \
- CTYPE "ctype functions" on \
- CURL"CURL support" off \
- DBA "dba support" off \
- DOM "DOM support" on \
- EXIF"EXIF support" off \
- FILEINFO"fileinfo support" off \
- FILTER "input filter support" on \
- FTP "FTP support" off \
- GD "GD library support" off \
- GETTEXT "gettext library support" off \
- GMP "GNU MP support" off \
- HASH"HASH Message Digest Framework" on \
- ICONV "iconv support" on \
- IMAP"IMAP support" off \
- INTERBASE "Interbase 6 database support (Firebird)" off \
- JSON"JavaScript Object Serialization support" on \
- LDAP"OpenLDAP support" off \
- MBSTRING"multibyte string support" off \
- MCRYPT "Encryption support" off \
- MSSQL "MS-SQL database support" off \
- MYSQL "MySQL database support" off \
- MYSQLI "MySQLi database support" off \
- ODBC"ODBC support" off \
- OPENSSL "OpenSSL support" off \
- PCNTL "pcntl support (CLI only)" off \
- PDF "PDFlib support (implies GD)" off \
- PDO "PHP Data Objects Interface (PDO)" on \
- PDO_SQLITE "PDO sqlite driver" on \
- PGSQL "PostgreSQL database support" off \
- PHAR"phar support" on \
- POSIX "POSIX-like functions" on \
- PSPELL "pspell support" off \
- READLINE"readline support (CLI only)" off \
- RECODE "recode support" off \
- SESSION "session support" on \
- SHMOP "shmop support" off \
- SIMPLEXML "simplexml support" on \
- SNMP"SNMP support" off \
- SOAP"SOAP support" off \
- SOCKETS "sockets support" off \
- SQLITE "sqlite support" on \
- SQLITE3 "sqlite3 support" on \
- SYBASE_CT "Sybase database support" off \
- SYSVMSG "System V message support" off \
- SYSVSEM "System V semaphore support" off \
- SYSVSHM "System V shared memory support" off \
- TIDY"TIDY support" off \
- TOKENIZER "tokenizer support" on \
- WDDX"WDDX support (implies XML)" off \
- XML "XML support" on \
- XMLREADER "XMLReader support" on \
- XMLRPC "XMLRPC-EPI support" off \
- XMLWRITER "XMLWriter support" on \
- XSL "XSL support (Implies DOM)" off \
- ZIP "ZIP support" off \
- ZLIB"ZLIB support" off
-
-ALL_OPTIONS= BCMATH BZ2 CALENDAR CTYPE CURL DBA \
+OPTIONS_DEFINE=BCMATH BZ2 CALENDAR CTYPE CURL DBA \
DOM EXIF FILEINFO FILTER FTP GD GETTEXT \
GMP HASH ICONV IMAP INTERBASE JSON LDAP MBSTRING MCRYPT \
MSSQL MYSQL MYSQLI \
@@ -113,10 +34,89 @@
TIDY TOKENIZER WDDX XML XMLREADER XMLRPC XMLWRITER XSL \
ZIP ZLIB
+BCMATH_DESC= bc style precision math functio
Re: Port system "problems"
On, Tue Jun 26, 2012, Mark Felder wrote: > On Tue, 26 Jun 2012 04:31:40 -0500, Andrea Venturoli > wrote: > > > > > The "effort" will be 3x processing time for portupgrade (or whatever) to > > update the package database 3 times as much as before. > > pkgng uses sqlite. Please provide proof that it is as slow or slower than > our current package database is. If I am trying to convince a customer of some solution X, I usually do not tell him to provide proof that the offered solution is worse than the current one when negotiating. Instead I try to convince him that the offered solution is better, more robust, future-proof, easier to maintain and saves tons of money. Please do not validate a system as good, just because noone yet provided some figures that outline that the existing system is in fact worse. That said, I might assume that the sqlite solution is faster, but noone can see that yet. Cheers Marcus pgpppmwwlATqu.pgp Description: PGP signature
Re: Port system "problems"
On, Tue Jun 26, 2012, Florent Peterschmitt wrote:
> On 26.06.2012 11:03, Matthew Seaman wrote:
> > On 26/06/2012 09:17, Andrea Venturoli wrote:
> >> On 06/26/12 09:58, Matthew Seaman wrote:
> >>> On 26/06/2012 08:26, Marcus von Appen wrote:
> >> 1. Ports are not modular
> > What do you mean by modular? if you are speaking about subpackages it
> > is coming,
> > but it takes time
> I hope, we are not talking about some Debian-like approach here
> (foo-bin,
> foo-dev, foo-doc, ).
> >>> Actually, yes -- that's pretty much exactly what we're talking about
> >>> here. Why do you feel subpackages would be a bad thing?
> >> Can I share my 2c?
> >>
> >> Because it will just multiply be three the number of ports each of us
> >> has to install/maintain/upgrade/etc...
> > Yes, it will multiply the number of ports. By three is about right,
> > given that most ports will only have port-docs and port-examples
> > sub-ports. However, first of all, you are assuming that the effort
> > required to install each of those sub-ports is the same as it is to
> > install a single port now. That is simply not the case.
> >
> > If you want to install the foo/bar port, then (as now) you'ld
> > essentially[+] --
> >
> > # cd ${PORTSDIR}/foo/bar
> > # make
> > # make install
> >
> > but you'ld end up with bar-0.99, bar-doc-0.99 and bar-examples-0.99
> > installed. Unless you have a setting like NOPORTDOCS or NOPORTEXAMPLES
> > (probably controlled by a dialogue menu like any other options) which
> > means you don't get the associated -docs or -examples sub-ports.
> >
> > That's no real change in terms of what you'ld have to do compared to now.
> >
> > The difference is that if you install from packages, you now have the
> > opportunity not to install docs or examples.
> >
> > Secondly, that's just one example of how sub-ports should work, and
> > docs/examples will be special-cased given their ubiquity. Most
> > sub-ports would be controlled by port OPTIONS dialogues.
> >
> > A typical example would involve client-server apps -- so mysqlNN-server
> > becomes a sub-port of mysqlNN-client. You get to check a box saying
> > 'install the server as well as the client' when you go to install
> > mysqlNN. Similarly all those php5-XYZ modules become sub-ports of
> > lang/php5. The big difference being that the port and all its sub-ports
> > are compiled in one step, and just packaged separately. Which is
> > probably less work overall that the current situation with ports and
> > slave-ports.
> >
> > Cheers,
> >
> > Matthew
> >
> > [+] Or more likely you'ld use portupgrade or portmaster or similar to
> > run these steps for you.
> >
> Hello,
>
> It's exactly what I wanted to say. I think so that port system should
> adapt to this way of building ports. I mean that is instead of having
> vala, we have vala-bin, vala-doc, vala-lib and vala-examples, and port
> system don't untar vala archive for each port, but once and pick up
> files into this unique directory. Then no waste of time because untar is
> what takes most time for big ports.
>
> We should still have a vala port, which is used to configure what we
> want (other subports -examples, -lib and -doc).
>
> But where it can be very useful, it's when we have a big port made of
> many libraries, like Mono. We should be able to split it, because I
> don't want to build everything.
I can't see that from the rough outline given earlier. What I understood
is that some stagedir is used to build mono, then packages (-lib, -doc,
-whatever) are created and installed.
If you do not use downloaded packages, but install them yourself, you'd
need to rebuild the complete mono port on an update.
Happy to be corrected here
Marcus
pgps2HkoVeLBo.pgp
Description: PGP signature
Re: Port system "problems"
On, Tue Jun 26, 2012, Jeremy Messenger wrote: > On Tue, Jun 26, 2012 at 3:44 AM, Baptiste Daroussin wrote: > > On Tue, Jun 26, 2012 at 10:34:00AM +0200, Marcus von Appen wrote: > >> Matthew Seaman : > >> > >> > On 26/06/2012 08:26, Marcus von Appen wrote: > >> 1. Ports are not modular > >> > > >> >>> What do you mean by modular? if you are speaking about subpackages it > >> >>> is coming, > >> >>> but it takes time > >> > > >> >> I hope, we are not talking about some Debian-like approach here > >> >> (foo-bin, > >> >> foo-dev, foo-doc, ). > >> > > >> > Actually, yes -- that's pretty much exactly what we're talking about > >> > here. Why do you feel subpackages would be a bad thing? > >> > >> Because it makes installing ports more complex, causes maintainers to rip > >> upstream installation routines apart, and burdens users with additional > >> tasks > >> to perform for what particular benefit (except saving some disk space)? > >> > >> If I want to do some development the Debian way, I would need to do the > >> following: > >> > >> - install foo-bin (if it ships with binaries) > >> - install foo-lib (libraries, etc.) > >> - install foo-dev (headers, etc.) > >> - install foo-doc (API docs) > >> > >> With the ports I am currently doing: > >> > >> - install foo > > I agree. > > > yes but you do not allow to install 2 packages one depending on mysql51 and > > one > > depending on mysql55, there will be conflicts on dependency just because of > > developpement files, the runtime can be made not to conflict. > > > > I trust maintainers to no abuse package splitting and do it when it make > > sense. > > > > In the case you give I would probably split the package that way: > > foo (everything needed in runtime: bin + libraries) > > foo-dev (everything needed for developper: headers, static libraries, > > pkg-config > > stuff, libtool stuff, API docs) > > foo-docs (all user documentation about the runtime) > > > > of course there will be no rule on how to split packages, just common sense. > > Disagree. We shouldn't split for that. Have you seen how many Linux > users report when they can't compile one of application, just because > they didn't install the *-dev? A LOT (thousands and thousands)! When > it's A LOT then it means that it's flawed. If the upstream provide the > split tarballs then I do not have any problem with it. Seconded. For newcomers, such a package system is as complex as an Ubuntu or Debian (under the hood), if they "just want to do X". Archlinux does provide complete packages, which makes perfect sense for me. I still do not see any reason or argument on why we would need sub-packages. Cheers Marcus pgpygwkrUSsvY.pgp Description: PGP signature
Re: Port system "problems"
On, Tue Jun 26, 2012, Baptiste Daroussin wrote: [...] > > >> 2. Option system is not really well documented > > > What kind of documentation do you need?, please report what you are > > > expected so > > > that we can improve it > > > > > >> 3. Some dependencies are totally useless > > > Please report PR > > > > > >> 4. So slow... > > > What is slow do you mean compiling is slow? > > > > > >> > > >> Let me give some examples: > > >> > > >> 1. games/wesnoth should be splitted in games/wesnoth-bin and > > >> games/wesnoth-datas. Why rebuild everything when just binaries needs ? > > > > > > This is coming, it takes lot of time, and some things have to be > > > done first, in > > > the infrastructure that the user do not see much. > > > > I do not see any necessity for infrastructure changes here - we did that > > in the past for several ports (e.g. alephone, alienarena, ...). > > No be able to have sub packages and flavours (aka N packages from one port) > there are changes needed Being able to and having the need to do something are two different things. Do we need this or do we make things more complex by taking sub-packages into consideration (for both or either one, the ports Makefile infrastructure and package tool(s))? Cheers Marcus pgp1DZHSh2HJA.pgp Description: PGP signature
Re: Port system "problems"
On Tue, 26 Jun 2012 13:42:54 -0500, Marcus von Appen wrote: That said, I might assume that the sqlite solution is faster, but noone can see that yet. The new system will be much, much better overall and people just need to stop making conclusions without knowing all the facts. It's going to be a heavily revamped system so people should stop comparing it to our current architecture. It's only similar on the surface. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: xfce 10 and icons
2012-06-26 19:10, Olivier Duchateau skrev: 2012/6/26 Thomas Zander : Hi, just that it does not get lost. This is the whole difference I observed: diff -rN config-old/.config/xfce4/xfconf/xfce-perchannel-xml/xsettings.xml .config/xfce4/xfconf/xfce-perchannel-xml/xsettings.xml 6c6 < --- You've found the patch ;) By the way, after the switching back and forth, two icons are still missing: Multimedia/Mixer and Settings/Keyboard. Not a big deal of course. You must add misc/gnome-icon-theme. Thanks again Riggs ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" The adding of x11-themes/icons-human-azul and change and back again also solved the problem for me :-) I'll install icons-human-azul next time I'm at the machine. Shouldn't these icon themes be marked as dependencies to xfce4 ? /Leslie ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On Tue, 26 Jun 2012 13:50:48 -0500, Marcus von Appen wrote: I still do not see any reason or argument on why we would need sub-packages. I want up to date packages for all my servers. My servers all have different requirements -- I want Apache with LDAP here, and definitely Apache without LDAP there. Designing a package-building and deployment system for a non-homogenous server farm is an exercise in futility. Having proper sub-packages fixes this issue in a cleanly supportable fashion. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Correction....Re: xfce 10 and icons
2012-06-26 21:02, Leslie Jensen skrev: 2012-06-26 19:10, Olivier Duchateau skrev: 2012/6/26 Thomas Zander : Hi, just that it does not get lost. This is the whole difference I observed: diff -rN config-old/.config/xfce4/xfconf/xfce-perchannel-xml/xsettings.xml .config/xfce4/xfconf/xfce-perchannel-xml/xsettings.xml 6c6 < --- You've found the patch ;) By the way, after the switching back and forth, two icons are still missing: Multimedia/Mixer and Settings/Keyboard. Not a big deal of course. You must add misc/gnome-icon-theme. Thanks again Riggs ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" The adding of x11-themes/icons-human-azul and change and back again also solved the problem for me :-) I'll install icons-human-azul next time I'm at the machine. Shouldn't these icon themes be marked as dependencies to xfce4 ? /Leslie ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" I meant that I'll install misc/gnome-icon-theme. /Leslie ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On, Tue Jun 26, 2012, Mark Felder wrote: > On Tue, 26 Jun 2012 13:50:48 -0500, Marcus von Appen > wrote: > > > I still do not see any reason or argument on why we would need > > sub-packages. > > I want up to date packages for all my servers. My servers all have > different requirements -- I want Apache with LDAP here, and definitely > Apache without LDAP there. Designing a package-building and deployment > system for a non-homogenous server farm is an exercise in futility. Having > proper sub-packages fixes this issue in a cleanly supportable fashion. That sound good to me and something I'd vote for, since it does not split ports on a technical, but functional level into packages. Cheers Marcus pgp7HNvIgfmrY.pgp Description: PGP signature
Re: Port system "problems"
On, Tue Jun 26, 2012, Mark Felder wrote: > On Tue, 26 Jun 2012 13:42:54 -0500, Marcus von Appen > wrote: > > > > That said, I might assume that the sqlite solution is faster, but noone > > can see that yet. > > > > The new system will be much, much better overall and people just need to > stop making conclusions without knowing all the facts. Then please provide facts. Do not get me wrong - I neither want to be nit-picking (well, just a bit ;-) nor I want to fight that idea by any means, but there was just a "sub-packages with StageDir will improve everything" rant without any arguments. > It's going to be a heavily revamped system so people should stop > comparing it to our current architecture. It's only similar on the > surface. Why should we stop to compare it? It aims to replace an architecture and hence performs similar tasks and tries to fulfill certain needs. That should qualify it for comparision in one or another way. Once more: I do not oppose the idea, but right now I do not see any sustainable concept nor anything else. I do not want all those working on it to run into a situation in which more people are unhappy with the solution provided. I also do not want to work with a system that burdens me with tasks that I do not _want_ to fulfill. This is why I ask about all those things, so I can throw in my to cents to make the system appealing for me. And thus I want to understand at least the big picture, concept and workflows. Cheers Marcus pgpLph6IJ1VT9.pgp Description: PGP signature
Re: Correction....Re: xfce 10 and icons
Leslie Jensen wrote .. > > > 2012-06-26 21:02, Leslie Jensen skrev: > > > > > > 2012-06-26 19:10, Olivier Duchateau skrev: > >> 2012/6/26 Thomas Zander : > >>> Hi, > >>> > >>> just that it does not get lost. This is the whole difference I observed: > >>> > >>> diff -rN > >>> config-old/.config/xfce4/xfconf/xfce-perchannel-xml/xsettings.xml > >>> .config/xfce4/xfconf/xfce-perchannel-xml/xsettings.xml > >>> 6c6 > >>> < > >>> --- > > >>> > >> > >> You've found the patch ;) > >> > >>> By the way, after the switching back and forth, two icons are still > >>> missing: Multimedia/Mixer and Settings/Keyboard. > >>> Not a big deal of course. > >> > >> You must add misc/gnome-icon-theme. > >> > >>> > >>> Thanks again > >>> Riggs > >>> ___ > >>> freebsd-ports@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports > >>> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > >> > >> > >> > > > > > > The adding of x11-themes/icons-human-azul and change and back again also > > solved the problem for me :-) > > > > I'll install icons-human-azul next time I'm at the machine. > > > > Shouldn't these icon themes be marked as dependencies to xfce4 ? > > > > /Leslie > > > > > > > > ___ > > freebsd-ports@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > > > I meant that I'll install misc/gnome-icon-theme. > > /Leslie > > > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ..Coming in late in the thread.. maybe this was already posted(?) But I think this issue is described in a pr, with an explanation and 3 possible solutions. http://www.freebsd.org/cgi/query-pr.cgi?pr=168688 -- Waitman Gobble San Jose California USA ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On 26/06/2012 19:46, Marcus von Appen wrote: > I can't see that from the rough outline given earlier. What I understood > is that some stagedir is used to build mono, then packages (-lib, -doc, > -whatever) are created and installed. > If you do not use downloaded packages, but install them yourself, you'd > need to rebuild the complete mono port on an update. > > Happy to be corrected here I don't know anything about the particulars of the mono port, but if it makes sense to divide it into several slave ports, then that will still be possible. Use of sub-ports is not going to be mandatory. Well, possibly with the exception of docs and/or examples, but that shouldn't be a huge burden for anyone. Remember what the big win is here: a binary package system that is fit for purpose and that preserves as much of the functionality and flexibility of the ports as possible. Yes, compiling from source yourself is the gold standard, but we think it would be pretty great if there was a binary package management system that was good enough that you don't actually /have/ to do that if you don't want to. Yes, it's complicated, but the ports is already hideously complicated, and I don't think this is that much worse: just moving the complication around a bit. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Port system "problems"
On Tue, 26 Jun 2012 14:43:11 -0500, Marcus von Appen wrote: That sound good to me and something I'd vote for, since it does not split ports on a technical, but functional level into packages. Yes this is exactly what we're aiming for. Right now if someone installs FreeBSD and they pkg_add apache22 and php5 they can't even serve PHP because php5 doesn't install mod_php. Things like this are as frustrating for new users as it is for people trying to maintain many, many servers. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On 2012-Jun-26 17:40:08 +0100, Chris Rees wrote: >Also, with pkgng the emphasis is more on binary upgrades. We really >shouldn't still be compiling from source for everything in this day >and age-- we're one of only two major projects that still do this as >the main upgrade solution. One of the big benefits of the FreeBSD ports system is that I can customise ports to suit my needs. I don't have choice forced upon me by a ports maintainer - who may have totally different requirements. I agree the current _package_ system has some rough edges (lack of synchronisation/serialisation to cope with parallel installs and poor overall performance) but I hope the ports build system will not be thrown out as part of the pkgng migration. -- Peter Jeremy pgpK4gPJGeALt.pgp Description: PGP signature
OpenMPI 1.6 port
Hello everybody As I had to deal with OpenMPI 1.6 packaging for my work, I thought that I could use the acquired knowledge to update the net/openmpi port after working hours. I've attached a tar containing the updated port directory, I hope it can help a bit the maintainers or interested people. I did not find any problem with a few basic programs. As this version changed a bunch of soname, it will impact any port depending on openmpi (freshports lists science/dlpoly-classic and science/meep). Regards, -- Matthieu Volat openmpi.tar.gz Description: Binary data ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port system "problems"
On 2012-Jun-26 20:50:48 +0200, Marcus von Appen wrote: >Archlinux does provide complete packages, which makes perfect sense for >me. I still do not see any reason or argument on why we would need >sub-packages. The most obvious reasons are the compiler ports. If I compile something (eg mplayer - which really wants gcc46) with gcc46 then the resultant executable has dependencies on support libraries supplied by gcc46 (eg lib/gcc46/libgcc_s.so.1). Currently, if I make a package of mplayer and try to install it on another system, then in order to satisfy the (~420KB) dependency on lib/gcc46/libgcc_s.so.1, it pulls is gcc46, which pulls in devel/binutils, math/gmp, math/mpfr and math/mpc - about 120MB. And if I'd selected gcj when I built gcc46 then the total would be about 300MB. This _is_ an issue when I'm installing into the fairly small SSD on my netbook. -- Peter Jeremy pgpuuezoeChnx.pgp Description: PGP signature
Re: Port system "problems"
On, Tue Jun 26, 2012, Matthew Seaman wrote: > On 26/06/2012 19:46, Marcus von Appen wrote: > > I can't see that from the rough outline given earlier. What I understood > > is that some stagedir is used to build mono, then packages (-lib, -doc, > > -whatever) are created and installed. > > If you do not use downloaded packages, but install them yourself, you'd > > need to rebuild the complete mono port on an update. > > > > Happy to be corrected here > > I don't know anything about the particulars of the mono port, but if it > makes sense to divide it into several slave ports, then that will still > be possible. Use of sub-ports is not going to be mandatory. Well, > possibly with the exception of docs and/or examples, but that shouldn't > be a huge burden for anyone. Right - we should be careful about how to split ports, however. And some -dev/-bin/-lib/-doc approach is nothing I would consider benefitial. A port with sub-packages based on functionality, which can be installed according to the use case provided by Mark makes more sense here. > Remember what the big win is here: a binary package system that is fit > for purpose and that preserves as much of the functionality and > flexibility of the ports as possible. Yes, compiling from source > yourself is the gold standard, but we think it would be pretty great if > there was a binary package management system that was good enough that > you don't actually /have/ to do that if you don't want to. Exactly. Also, you need to consider the maintainers. It must be ensured, that they do not have to fiddle with nth of sub-package adjustments just to support those properly. Cheers Marcus pgpurm120WTtX.pgp Description: PGP signature
Re: Port system "problems"
On Tue, Jun 26, 2012 at 1:56 PM, Peter Jeremy wrote: > but I hope the ports build system will not > be thrown out as part of the pkgng migration. Where do you think packages would come from, if not built by the ports tree? ;) -- Freddie Cash fjwc...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: OpenMPI 1.6 port
On Tue, Jun 26, 2012 at 1:58 PM, Matthieu Volat wrote: > Hello everybody > > As I had to deal with OpenMPI 1.6 packaging for my work, I thought that I > could use the acquired knowledge to update the net/openmpi port after working > hours. > > I've attached a tar containing the updated port directory, I hope it can help > a bit the maintainers or interested people. I did not find any problem with a > few basic programs. > > As this version changed a bunch of soname, it will impact any port depending > on openmpi (freshports lists science/dlpoly-classic and science/meep). > > Regards, ports@ does not maintain openMPI. This really should be put into a PR or, at very least sent to the maintainer (brooks@). -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: php53-extensions-1.6 doesn't work with OPTIONSng
Miroslav Lachman wrote:
Miroslav Lachman wrote:
Hi,
I tried to install or update php53-extensions on few machines and I
always found a same bug.
My options are ignored and php53-extensions are installed with default
set of extensions.
It's because Makefile contains old OPTIONS style.
[...]
So the port lang/php53-extensions needs to be converted to OPTIONSng as
lang/php5-extensions was.
I tried the attached patch and it works for me.
And there are two quick patches for lang/php53. They need better review
and testing as I did not test all possible options combinations. It is
merged from lang/php5.
Miroslav Lachman
--- Makefile.orig 2012-06-25 23:07:17.0 +0200
+++ Makefile2012-06-26 23:33:12.0 +0200
@@ -20,6 +20,7 @@
USE_BZIP2= yes
MAKE_JOBS_SAFE=yes
+NO_OPTIONS_SORT=yes
.if !defined(PKGNAMESUFFIX)
USE_AUTOTOOLS= autoconf
@@ -39,17 +40,20 @@
USE_GNOME= libxml2
-OPTIONS= CLI "Build CLI version" on \
- CGI "Build CGI version" on \
- FPM "Build FPM version (experimental)" off \
- APACHE "Build Apache module" off \
- AP2FILTER " Use Apache 2.x filter interface (experimental)" off
\
- DEBUG "Enable debug" off \
- SUHOSIN "Enable Suhosin protection system" on \
- MULTIBYTE "Enable zend multibyte support" off \
- IPV6 "Enable ipv6 support" on \
- MAILHEAD "Enable mail header patch" off \
- LINKTHR "Link thread lib (for threaded extensions)" off
+OPTIONS_DEFINE=CLI CGI FPM APACHE AP2FILTER DEBUG SUHOSIN MULTIBYTE
IPV6 MAILHEAD LINKTHR
+OPTIONS_DEFAULT=CLI CGI SUHOSIN IPV6
+
+CLI_DESC= Build CLI version
+CGI_DESC= Build CGI version
+FPM_DESC= Build FPM version
+APACHE_DESC= Build Apache module
+AP2FILTER_DESC=Use Apache 2.x filter interface (experimental)
+DEBUG_DESC=Enable debug
+SUHOSIN_DESC= Enable Suhosin protection system
+MULTIBYTE_DESC=Enable zend multibyte support
+IPV6_DESC= Enable ipv6 support
+MAILHEAD_DESC= Enable mail header patch
+LINKTHR_DESC= Link thread lib (for threaded extensions)
CONFLICTS= php52-5* php5-5*
@@ -62,7 +66,7 @@
PATCH_SITES+= ${MASTER_SITE_LOCAL}
PATCH_SITE_SUBDIR= ale
-.if !defined(WITHOUT_SUHOSIN)
+.if ${PORT_OPTIONS:MSUHOSIN}
PATCHFILES+= suhosin-patch-5.3.x-0.9.10.patch.gz
PATCH_SITES+= http://download.suhosin.org/:suhosin
PLIST_SUB+=SUHOSIN=""
@@ -70,12 +74,12 @@
PLIST_SUB+=SUHOSIN="@comment "
.endif
-.if defined(WITH_MAILHEAD)
+.if ${PORT_OPTIONS:MMAILHEAD}
PATCHFILES+= php-5.3.x-mail-header.patch:mail
PATCH_SITES+= http://choon.net/opensource/php/:mail
.endif
-.if !defined(WITHOUT_CLI)
+.if ${PORT_OPTIONS:MCLI}
PHP_SAPI+= cli
PLIST_SUB+=CLI=""
MAN1+= php.1
@@ -84,7 +88,7 @@
CONFIGURE_ARGS+=--disable-cli
.endif
-.if !defined(WITHOUT_CGI)
+.if ${PORT_OPTIONS:MCGI}
PHP_SAPI+= cgi
PLIST_SUB+=CGI=""
.else
@@ -92,7 +96,7 @@
CONFIGURE_ARGS+=--disable-cgi
.endif
-.if defined(WITH_FPM)
+.if ${PORT_OPTIONS:MFPM}
PHP_SAPI+= fpm
MAN8+= php-fpm.8
USE_RC_SUBR+= php-fpm
@@ -104,11 +108,11 @@
PLIST_SUB+=FPM="@comment "
.endif
-.if defined(WITH_APACHE)
+.if ${PORT_OPTIONS:MAPACHE}
PHP_SAPI+= mod
USE_APACHE=20+
.include "${PORTSDIR}/Mk/bsd.apache.mk"
-.if defined(WITH_AP2FILTER)
+.if ${PORT_OPTIONS:MAP2FILTER}
CONFIGURE_ARGS+=--with-apxs2filter=${APXS}
.else
CONFIGURE_ARGS+=--with-apxs2=${APXS}
@@ -140,26 +144,26 @@
pthreads_working="yes" \
lt_cv_path_SED="sed"
-.if defined(WITH_LINKTHR)
+.if ${PORT_OPTIONS:MLINKTHR}
CONFIGURE_ENV+=LIBS="${LIBS} ${PTHREAD_LIBS}"
.endif
-.if defined(WITH_DEBUG)
+.if ${PORT_OPTIONS:MDEBUG}
CONFIGURE_ARGS+=--enable-debug
.endif
-.if defined(WITH_MULTIBYTE)
+.if ${PORT_OPTIONS:MMULTIBYTE}
CONFIGURE_ARGS+=--enable-zend-multibyte
.endif
-.if defined(WITHOUT_IPV6)
+.if empty(PORT_OPTIONS:MIPV6)
CONFIGURE_ARGS+=--disable-ipv6
.endif
post-patch:
@${TOUCH} ${WRKSRC}/ext/php_config.h
@${REINPLACE_CMD} "s|^\(extension_dir\)|; \1|" ${WRKSRC}/php.ini-*
-.if defined(WITH_FPM)
+.if ${PORT_OPTIONS:MFPM}
@${REINPLACE_CMD} -e "s|^;\(pid\)|\1|;s|^;\(pm\.[a-z_]*_servers\)|\1|" \
${WRKSRC}/sapi/fpm/php-fpm.conf.in
.endif
@@ -185,10 +189,10 @@
@${INSTALL_DATA} ${WRKSRC}/php.ini-production ${PREFIX}/etc
@${INSTALL_DATA} ${WRKDIR}/php.conf ${PREFIX}/etc
@${TOUCH} ${PREFIX}/include/php/ext/php_config.h
-.if defined(WITH_FPM)
+.if ${PORT_OPTIONS:MFPM}
@${CP} -n ${PREFIX}/etc/php-fpm.conf.default ${PREFIX}/etc/php-fpm.conf
.endif
-.if defined(WITH_APACHE)
+.if ${PORT_OPTIONS:MAPACHE}
@${CAT} ${PKGMESSAGE}
.endif
--- Makefile.ext.orig 2012-06-25 23:07:17.0 +0200
+++ Makefile.ext2012-06-27 00:06:46.0 +0200
@@ -40,12 +40,15 @@
.if ${PHP_MODNAM
