Solved Single tool for maintaining everything

Rastko

Rastko

Hi,

Couple of questions about portmaster.

Given that the documentation and some tools related to the "ports" system regard programs installed from binary package repository as "ports", does that mean:

1. We can use tools like portmaster to manage everything, regardless of the way it was installed in the first place?

2. Can we update packages from binary repositories using portmaster? Can we use it inplace of the pkg tool?

I prefer binary packages for installation, but want to customize some options using the "ports" system.

3. Am I correct in stating that "package" refers to an installer and "port" refers to the application, regardless of how it was installed?

4. Can I make portmaster tool only deal with ports "ports" repo or only with packages binary repos?
 
Rastko said:
Can we update packages from binary repositories using portmaster? Can we use it inplace of the pkg tool?
Click to expand...
Quick and simple answer, no.

Rastko said:
Am I correct in stating that "package" refers to an installer and "port" refers to the application, regardless of how it was installed?
Click to expand...
A package is a pre-compiled port. A port is a collection of files that tell the system how to build an application. Ports build packages and it's this package that eventually gets installed. So in the end they're all packages.
 
SirDice said:
Quick and simple answer, no.


A package is a pre-compiled port. A port is a collection of files that tell the system how to build an application. Ports build packages and it's this package that eventually gets installed. So in the end they're all packages.
Click to expand...


So... You can't use portmaster to upgrade packages installed with pkg, but can you manage/upgrade something installed with portmaster using pkg or that doesn't work either?
 
Given the explanation of SirDice, one must note that WE CAN'T MIX PRECOMPILED PACKAGES, and PORTS COMPILATION, and this seems to be what you want to do.

A precompiled package is just a regular port compiled with the default dependency chain/options defined by the port admnistrators, but when you compile yourself a port, you will generally define your own compilation options and you will break this default dependency chain. So attempting to update a precompiled package, pkg will detect incompatible packages and will deinstall all of them before installing updates.... a real mess. On the contrary, you may be unable to choose a specific option for a given port as this option would be incompatible with a precompiled package already installed.

Just understand that pre-compiled packages and packages compiled yourself from port comply exactly to the same archive format, this is not the question here, the question is that your own packages use their own chain of dependency.

So you must choose port system or precompiled binaries NOT BOTH

This is a recurrent question on this forum, there are many people trying to mix, after hours of discussions there is only one conclusion.
 
SirDice said:
Quick and simple answer, no.


A package is a pre-compiled port. A port is a collection of files that tell the system how to build an application. Ports build packages and it's this package that eventually gets installed. So in the end they're all packages.
Click to expand...

Thanks for clarifying, I knew that intuitively. I have read the FreeBSD handbook many times over, and find manual pages very informative. However, sometimes I get lost.

For example, portmaster tool has the -PP option, which doesn't combine with the -L parameter, however, pkg version has -P -I and -R options, which allow you to check versions. That seems like a discrepancy.

Contradiction is noticed in your answer as to the fact that "in the end they're all packages" and Wozzeks remark on not mixing packages and ports. However, I am not talking about a single application, I am comparing systems.

portmaster has many options that allow you to deal with packages, and pkg doesn't have many options that allow you to deal with ports.

As for dependency chains, I guess it's a bit like Solaris's package group constraints, right? (I forgot the exact term)
 
SirDice said:
It has none actually, pkg(8) only deals with packages and only packages.
Click to expand...

What does
Code: 
pkg version -l "<"
or
Code: 
pkg version -P -l "<"
or
Code: 
pkg version -I -l "<"
produce? Why the need for -R?

I fall into this trouble because of diskspace. Can't build my own repos, only 88 GB alloted to FreeBSD.
 
OK,

portmaster -- outdated
pkg (NG) -- where it's at
portupgrade -- will get into it
portsnap -- will have to get into CVS, although I'm finding git hard to grasp.
synth, dovecot, poudriere -- diskspace limiting?
 
Note that portmaster(8) isn't out-dated. It's a tool primarily intended to help build ports.

portsnap(8) is a tool to update the ports tree. It has nothing to do with CVS. Besides that, CVS has been deprecated in favor of SVN a long time ago.

dovecot(1) is a POP3/IMAP service, it has nothing to do with ports or packages.


Simple list:
portmaster(8) and portupgrade(1) are both tools to help build ports.
pkg(8) is a tool to manage packages
portsnap(8) is used to maintain a local ports tree copy.
synth(1) and poudriere(8) are tools to help build your own package repository from ports.
 
Wozzeck.Live said:
Given the explanation of SirDice, one must note that WE CAN'T MIX PRECOMPILED PACKAGES, and PORTS COMPILATION, and this seems to be what you want to do.

A precompiled package is just a regular port compiled with the default dependency chain/options defined by the port admnistrators, but when you compile yourself a port, you will generally define your own compilation options and you will break this default dependency chain. So when you will attempt to update a precompiled package, pkg will detect incompatible packages and will deinstall all of them before installing update.... a real mess. On the contrary, you may be unable to choose a specific option for a given port as this option would be incompatible with a precompiled package already installed.

Just understand that pre-compiled packages and packages compiled yourself from port comply exactly to the same archive format, this is not the question here, the question is that your own packages use their own chain of dependency.

So you must choose port system or precompiled binaries NOT BOTH

This is a recurrent question on this forum, there are many people trying to mix, after hours of discussions there is only one conclusion.
Click to expand...

When you say "mix", what exactly do you mean? Which brings me to the next question:
When you say "dependency chain", do you mean that both reverse and forward dependencies?

In that case, anytime you build a port with custom options, you are "mixing" ports and precompiled packages?
What if you do not customize defaults in ports? Do you break the dependency chains?[/b]
 
SirDice said:
Note that portmaster(8) isn't out-dated. It's a tool primarily intended to help build ports.

portsnap(8) is a tool to update the ports tree. It has nothing to do with CVS. Besides that, CVS has been deprecated in favor of SVN a long time ago.

dovecot(1) is a POP3/IMAP service, it has nothing to do with ports or packages.


Simple list:
portmaster(8) and portupgrade(1) are both tools to help build ports.
pkg(8) is a tool to manage packages
portsnap(8) is used to maintain a local ports tree copy.
synth(1) and poudriere(8) are tools to help build your own package repository from ports.
Click to expand...

What about other "--package-*" options for portmaster? Which ones are deprecated?

A bit off topic, but it seems gnustep-app metaport was removed from repository, so most of the gnustep apps are registered by "pkg autoremove". Do I have to use "pkg set"?
 
Rastko said:
When you say "mix", what exactly do you mean?
Click to expand...
Mixing ports and (official) packages. The official packages are always built using the port's default options. When you build something from ports you can enable/disable those options or change the default Ruby version for example. This can lead to differences in dependencies, your ports for example may have been built with Ruby 2.1 as the default but the official packages use Ruby 2.3. A careless pkg-upgrade(8) will remove all your Ruby 2.1 ports and replaces them with the default Ruby 2.3. Which is probably not what you want. Hence it's recommended not to mix ports and (official) packages unless you know what you are doing.

Rastko said:
When you say "dependency chain", do you mean that both reverse and forward dependencies?
Click to expand...
Correct. Both can be mismatched.
Rastko said:
In that case, anytime you build a port with custom options, you are "mixing" ports and precompiled packages?
Click to expand...
Not if you build everything from ports. Custom built packages are a different matter. Probably a better way would be to say; Don't mix ports with official packages.
Rastko said:
What if you do not customize defaults in ports? Do you break the dependency chains?
Click to expand...
If you stick to the default settings and options there's no reason to use a port in the first place. You will gain nothing by building them yourself in that case.
 
So my mixup is between pre-compiled dependency chains and customized port dependency chains? Now that is a mess. It makes you use one or the other the whole way? Then it is confusing that, as per the manual page, portmaster(8)() has various --package-* options.
 
Rastko said:
A bit off topic, but it seems gnustep-app metaport was removed from repository, so most of the gnustep apps are registered by "pkg autoremove". Do I have to use "pkg set"?
Click to expand...
Yes, that's the correct way to do it. Those packages have been automatically installed and will get removed because there's nothing depending on them any more. If you want to keep (some of) them, you will need to mark them as 'not-automatic'.
 
Rastko said:
So my mixup is between pre-compiled dependency chains and customized port dependency chains? Now that is a mess.
Click to expand...
Yes, you can get into a really big mess if you're not careful. Which is why a lot of us build our own repositories. This has several benefits, you're building from ports so you have complete control over options, default versions, etc. Because everything comes from the same repository you don't run into the "dependency hell" (not easily anyway). And you keep the ease of using pkg(8) to update/upgrade your systems. It's having the best of both worlds.
 
SirDice said:
Yes, you can get into a really big mess if you're not careful. Which is why a lot of us build our own repositories. This has several benefits, you're building from ports so you have complete control over options, default versions, etc. Because everything comes from the same repository you don't run into the "dependency hell" (not easily anyway). And you keep the ease of using pkg(8) to update/upgrade your systems. It's having the best of both worlds.
Click to expand...

Now that you mentioned it, I DO have a 64 GB dedicated partition for packages for Windows. If I split it up into two, will 32 GB be enough for my own repository of selected development and multimedia tools?

EDIT

Also, what you're saying is pkg()( will work with any repository as long as it's a singular repository?
 
Rastko said:
Now that you mentioned it, I DO have a 64 GB dedicated partition for packages for Windows. If I split it up into two, will 32 GB be enough for my own repository of selected development and multimedia tools?
Click to expand...
That's probably enough, for reference:
Code: 
dice@molly:~ % zfs list fbsd1/poudriere/data
NAME                   USED  AVAIL  REFER  MOUNTPOINT
fbsd1/poudriere/data  13.6G  1.60T  13.6G  /usr/local/poudriere/data
This contains 4 repositories, for 10.3-RELEASE and 11-STABLE with a desktop and server repository for each.

Rastko said:
Also, what you're saying is pkg()( will work with any repository as long as it's a singular repository?
Click to expand...
pkg(8) can deal with multiple repositories. But to keep things clear and simple it's best to stick to one. One of my servers uses two repositories, one server based (no X11) and one desktop based repository because I have a need for certain desktop tools there. But as both come from my own repository I can make sure the dependencies line up as much as possible and so there's very little risk of things clashing.
 
You must log in or register to reply here.
Back
Top