Searching for easy package manager

B

bsus

Hi,

I really like FreeBSD but the ports are kind of hard after a while. You lose the overview of everything and you have to act with four different tools to update. Especially updating is a thing for its own and seems like a infinite process comprared with as example pacman. My question was now if there is a portage-like or a pacman-like portmanager?

Regards
 
An overview of several commands, details left out of the entire process:
As far as pacman-like, maybe a shell script wrapping the following.
Code: 
portmaster -PP opencv-core
portmaster -d -B -P -i /var/db/pkg/sudo-# /var/db/pkg/smartmontools-# /var/db/pkg/net-snmp-# && yell (ttyload) || yell (ttyload) 
# install /yell/ or /ttyload/ first maybe
With the latter(yell|ttyload) command, you can be summoned back if it fails OR succeeds, though the pkg-messages displayed at the end of installs will wait for your return without yell or ttyload activating. If one has a file, say UPDATE_FILE with p5-,s /graphics/, /www/, etc one can
Code: 
grep www UPDATE_FILE | awk '{print $1}' | xargs -J % portmaster -d -P -B -i %
if the file is of the form (the result of a command run by many Freebsd users, if tee'd into a file)

www/firefox. . . . needs updating...
www/epiphany. . . . needs updating...
devel/p5-IPC-Run. . . . needs updating...

(the first field (the port) will be printed by awk into portmaster, which in
this case may start to update 2 of the three)
That is how I usually update nowadays, most everyone does it different maybe.
 
Hi,
thanks for the fast answer.

Portmaster gives me:
Code: 
freebsd ~ # portmaster       

===>>> No valid installed port, or port directory given
===>>> Try portmaster --help

By the side, wouldn't it be recommand for me to completly use packages.
Because I don't really configure the makefiles except bigger ports like samba or apache.

Regards
 
Here all I use is a script by DutchDaemon to check for updates (http://forums.freebsd.org/showpost.php?p=39092&postcount=37) and then ports-mgmt/portmaster to update where needed.

You can instruct ports-mgmt/portmaster to only use packages (-PP), or use packages when these are up-to-date and otherwise compile (-P). Please refer to the manual of portmaster(8) for more details, or ask here when in doubt.

To update all ports, I normally run (after running DutchDaemon's script):

# portmaster -dbvPa

And to install or update a (single) port:

# portmaster -dbvP <category>/<port>

For something with a GUI you may look at ports-mgmt/portrac and ports-mgmt/bxpkg.
 
SNK, If you want to link to a port's manpage, use portmaster(8).() manual page" href="https://man.freebsd.org/cgi/man.cgi?query=, so portmaster(8).&sektion=&manpath=freebsd-release-ports">, so portmaster(8).()() manual page" href="https://man.freebsd.org/cgi/man.cgi?query=, not portmaster(8).() manual page" href="https://man.freebsd.org/cgi/man.cgi?query=, so portmaster(8).&sektion=&manpath=freebsd-release-ports">, so portmaster(8).()&apropos=0&sektion=&manpath=freebsd-ports&format=html">, not portmaster(8).() manual page" href="https://man.freebsd.org/cgi/man.cgi?query=, so portmaster(8).&sektion=&manpath=freebsd-release-ports">, so portmaster(8).()()
 
bsus said:
I really like FreeBSD but the ports are kind of hard after a while. You lose the overview of everything and you have to act with four different tools to update.
Click to expand...

What are the four different tools? Usually some things can be combined in a small script. I have one that updates the ports tree and shows updates that are available for installed ports.

If there are updates available, then less(1) to check the latest entries in /usr/ports/UPDATING. If there are special instructions, follow those, otherwise use portmaster(8) as normal.

Upgrading FreeBSD Ports
 
I keep forgetting about pkg_updating(1). As a suggestion, use the earlier of one week or the date of the most recent directory in /var/db/pkg.
% pkg_updating -d `ls -D %Y%m%d -ltr /var/db/pkg | tail -n1 | tr -s " " "\t" | cut -f 6`
 
I save a file with the date of the last run (DutchDaemon portupdate) then pass it in next run but your "hieroglyphs" are better, much better
 
wblock@ said:
I keep forgetting about pkg_updating(1). As a suggestion, use the earlier of one week or the date of the most recent directory in /var/db/pkg.
% pkg_updating -d `ls -D %Y%m%d -ltr /var/db/pkg | tail -n1 | tr -s " " "\t" | cut -f 6`
Click to expand...

If I read this correctly you're running the risk of not seeing a late addition to UPDATING. I've seen more than one instance of installation instructions being added to UPDATING a day or more after the actual port was updated and installed. Using the line above would obscure that late entry from view, if I'm not mistaken. To get 'the earlier of one week or the latest entry in /var/db/pkg' one would have to push the date back one week. In other words: the date should never be more recent than one week ago, regardless of the most recent file in /var/db/pkg.
 
Code: 
weekago=$( /bin/date -v-1w +%Y%m%d ) [B](e.g. 20111031)[/B]
lastpkg=$( ls -D %Y%m%d -ltr /var/db/pkg | /usr/bin/tail -n1 | /usr/bin/tr -s " " "\t" | /usr/bin/cut -f 6 ) [B](e.g. 20111107)[/B]
if [ ${weekago} -lt ${lastpkg} ]
then usedate=${weekago}
else usedate=${lastpkg}
fi
/usr/sbin/pkg_updating -d ${usedate} [B](will be 20111031 here)[/B]

Something like that anyway. If your last port update/install took place over a week ago, all relevant entries in UPDATING since that time will be shown. The relevant entries of the last week will always be shown.

I have updated the script with this. Thanks for the input!
 
Yes, it's just to cover when the last port update was more than a week ago. Dates in /var/db/pkg aren't foolproof, but I haven't found a better automatic way.
 
This thread is solved and I'm going OT a bit. I don't know if I understood what DutchDaemon said before, what I understook is that the last updated pkg date should not be the right one to take a date limit in searching for updates for all packages. I wrote this perl script that take updates for all installed packages taking care of the date each one was last updated (this is english?). The script is only a tests and display many unuseful text but it should works. This is useful if, as an example, an package update is not done when you run the updater script (DutchDaemon updater script) and leave it unupdated for months, due to lazyness or simply because you think it is not strictly necessary.


Code: 
#! /usr/local/bin/perl
use strict;
use warnings;

# Items in packages are objects (hashes) defined as follow
#	name			The package name
my @packages = ();

my $hdir;
my $pkgdir = "/var/db/pkg";
opendir ($hdir, $pkgdir);
my @items = readdir ($hdir);
my @dirs = undef;
my $dir;
my @fs;
my $s;
foreach $dir (@items)
{
    $s = $pkgdir . "/" . $dir;
    if ((-d $s) and ($dir !~ /^\.+$/))
    {
        # get port name
        my $port = `pkg_info -q -o $dir`;
        chomp ($port);
        # get last modified pkg date
        @fs = stat ($s);
        my @dt = localtime ($fs[9]);
        my $date = sprintf ("%4i%02i%02i", 1900 + $dt[5], $dt[4] + 1, $dt[3]);
        # get updating info for the pkg
        my $updinfo = `pkg_updating -d $date $port`;
        # create pkg object
        my %pkg = ( "name" => $dir,
                    "port" => $port,
                    "date" => $date,
                    "updates" => $updinfo );
        push (@packages, \%pkg);
    }
}
PrintPkgs (@packages);

# Function: PrintPkgs
#	...
sub PrintPkgs
{
    my $pkg;
    foreach $pkg (@_)
    {
        print ("pkg: " . $pkg->{"name"} . "\n");
        print ("    port: " . $pkg->{"port"} . "\n");
        print ("    date: " . $pkg->{"date"} . "\n");
        if (defined ($pkg->{"updates"}))
            { print ("    updates: " . $pkg->{"updates"} . "\n"); }
        else
            { print ("    updates: undef\n"); }
    }
}
 
My way of handling and displaying UPDATING entries relies on the assumption that the user does not selectively update ports, but rather keeps them all updated, or updates all of them at the same time every time. So we're basically talking about users who keep everything up-to-date on a regular (daily, weekly, maybe monthly) basis.
 
Updating some ports without updating others starts getting shaky very quickly, although people try.

Beware that the dates in /var/db/pkg can be changed by things other than a real update. portmaster --check-depends, for example.
 
DutchDaemon said:
My way of handling and displaying UPDATING entries relies on the assumption that the user does not selectively update ports, but rather keeps them all updated, or updates all of them at the same time every time. So we're basically talking about users who keep everything up-to-date on a regular (daily, weekly, maybe monthly) basis.
Click to expand...

wblock@ said:
Updating some ports without updating others starts getting shaky very quickly, although people try.
Click to expand...

Yes, it's better to update all at the same time, however I don't strictly follow the rules, i.e. there are situations I postpone some updates, this happens for ports that takes many times to compile and aren't a critical dependency for other ports or there are no ports that depends on it at all (leaves). Another situation is when after 2 or 3 weeks without updating ports, the new updating list is too big and selectively update ports in 'lots' and sometimes happens to re-run the updater script when not all lots are updated. However this situation is not usual.

wblock@ said:
Beware that the dates in /var/db/pkg can be changed by things other than a real update. portmaster --check-depends, for example.
Click to expand...

This probably should be solved looking at date of some installed files in pkg-plist file in the port directory, but don't know if this method is valid for all ports. Perhaps the solution is to associate the version with a date, every version is fixed at the release time (a field in port Makefile) it is modified when port is modified and should follow the package (a field in +CONTENTS) this one is the checked date for each package.

Anyhow, I modified the updater script as above and it works better than before without maintaining a file, thanks both wblock and DutchDaemon for this.
 
You must log in or register to reply here.
Back
Top