Learn about Linux
Download Linux
Get Linux helpSpecial Offers
Feature
New approaches to Linux package management
Share
Print
CommentsLinux is available for a number of architectures, which is one of its advantages. However, most packages are generally compiled only for i386, or i686 -- leaving users of alternative architectures with a dilemma. Users wanting packages optimized for other architectures often have to wait longer for pre-compiled packages, or resort to compiling the packages from source on their own, which defeats the purpose of using a package manager.
Availability of binary packages is also a problem for certain projects. I am an avid fan of KDE and a Slackware user. Every time a new version of KDE is released it takes a week or two until the Slackware packages are available, and the alternative, compiling KDE from source, with all its dependencies, can take an entire day.
Another problem with existing package management systems is that they contain scripts that automate the installation. However, if the scripts contain bugs, then users may need to employ complicated workarounds to rectify the problems. Even worse, if a package's installation script fails, it might be impossible to remove the package without extensive manual effort.
A new breed of distributed package management systems have emerged which make use of Internet-based repositories to give users the packages they require, customized for each user's architecture.
Gentoo Portage
The Portage package management system is a central feature of the Gentoo Linux distribution. Portage, which takes after the Ports system used with *BSD distributions, is a pioneer in the distributed package management paradigm for GNU/Linux distributions.
Portage uses the rsync protocol to update its tree. Updating all of the software in the entire distribution is as simple as entering the command:
emerge --sync
This command updates the local Portage tree with the current Portage tree for Gentoo. To update all of the packages on your system, run emerge -u world.
What about installing new software? To search for a specific package, simply run emerge --search packagename .
Portage can also handle dependencies automatically. To install a package, run:
emerge packagename
This emerge command tells Portage to download the source code of a specified application, as well as all other applications or libraries needed to satisfy its dependencies. Once downloaded, everything is compiled from source. You can optimize the compilation settings through the CFLAGS environment variable, based on the specifications of the individual computer, and on the individual user's need for speed.
One drawback of Portage is that it relies on the Gentoo Portage tree. If a package is not available in the tree, then a user cannot use Portage to install the package, and must resort to compilation by source.
Portage is one of the innovations that has enabled Gentoo to gain a large user-base very quickly, and it solves several of the problems found with traditional package managers.
The Conary Software Provisioning SystemThe Conary Software Provisioning System is developed by rPath, a company founded by ex-Red Hat engineers. Conary applies new ideas from distributed configuration management tools such as GNU arch and monotone.
According to the designers, "Conary uses networked repositories containing a structured version hierarchy of all the files and organized sets of files in a distribution."
Rather than concentrating on separate package files in the manner of traditional package managers, Conary relies on a tree-like structure that resembles to a software configuration control system. The Conary tree, unlike the Portage tree, can be distributed across a network. That is, a package compiled for i386 can be kept in the repository at rpath.com, and someone else might maintain the package for an alternate platform in another repository. The Conary tree can span multiple repositories, and hence potentially provide access to a vast array of packages.
Conary is able to utilize binaries if available, or source if necessary, and stores all version information in a database in order to track changes from the source branch all the way back to changes in the local versions installed on a given system to meet dependencies without conflicts. In some ways, Conary acts as a revision control system for package management.
Conary's command-line syntax is very APT-like, and the GUI front end is similar to Synaptic. Conary is designed for the layman, and hence it is easy to use. For example, here are some of the commands for popular operations with package managers:
The command conary q packagename shows whether a given package is installed.
The command conary rq packagename lists the newest available upgrade.
The command conary update packagename installs or updates the requested package.
The command conary erase packagename uninstalls the package.
Say I want to upgrade KDE on a Conary-based system. Running conary update KDE resolves all dependencies and updates all of the necessary packages for KDE.
Conary is an exciting tool for users who are frustrated with traditional package management systems. At least two distributions make use of Conary for package management: rPath, which was created by the designers of Conary, and Foresight Linux .
Conclusion
Conary and Portage were designed to address many of the limitations of traditional package manager. The Linux developer and user base has grown enormously over the past decade, and packaging systems have not kept pace. Many do not scale well to multiple repositories with conflicting or overlapping content, which can make it difficult for developers on different projects to coordinate package releases. Additionally, the increasing number of dependencies in many open source packages poses unique challenges to open source package managers.
One of the main aims of Conary is that it should be designed to enable a loosely coupled Internet-based collaborative approach to building Linux distributions that can change almost any aspect of a Linux system. With this kind of approach, Linux users might be able to manage their distributions with ease and not have to change their operating systems in order to circumvent the frustrations of a traditional package management system.
With the new breed of package managers users can now relegate responsibility for management of all aspects of software installation, upgrades, and removal to the package manager. With any luck, the days when users have to scour the Internet for optimized packages or missing dependencies will soon be over.
Comments
on New approaches to Linux package managementNote: Comments are owned by the poster. We are not responsible for their content.
1. A repository was moved and I did not know of the change.
2. Packaging errors made by the person creating the dep, rpm whatever. This is the most common.
Those are the only two real instances ICR. Oh there may have been the odd occasion where there a bug in the program itself.
But none of those can be avoided no matter what management system you use. As for one universal no matter what distro you use packaging system, well, keep your dirty mitts off my sourced based distro.
Source-based is univeral, nothing else really is
Posted by: Anonymous Coward on November 11, 2005 06:30 AMExample:
tar xzvf mypackage-3.1.tar.gz
cd mypackage-3.1.tar.gz<nobr> <wbr></nobr>./configure make
sudo make install --prefix=/usr/local/packages/mypackage-3.1
cd<nobr> <wbr></nobr>/usr/local/package
sudo xstow mypackage-3.1
and to uninstall something:
xstow -d mypackage-3.1
rm -rf<nobr> <wbr></nobr>/usr/local/packages/mypackage-3.1
Of course you don't have dependency tracking, etc, but I haven't yet seen any form of dependency tracking that was actually cross-distro and actually worked...
Of course, honestly, I haven't yet found a problem with Debian... I mostly use stow on my mac laptop to install debian-sourced packages (apt-get source and rsync are your friend) so that the scripts I use to manage stuff at my day job work whether I'm on one of the management servers or my laptop.
If you're on debian, of course, it's usually as easy to debianize a package as it is to use stow. software that uses standard configure script will usually debianize automatically, and the other kinds need manual handholding for debianizing AND stow.
Of course, keeping a few locally-debianized (rpmed, whatever) packages up to date is a lot easier than keeping an entire source-based distro up to date...
Re:Source-based is univeral, nothing else really i
Posted by: Anonymous Coward on November 11, 2005 04:34 PM>
> tar xzvf mypackage-3.1.tar.gz
> cd mypackage-3.1.tar.gz<nobr> <wbr></nobr>./configure make
> sudo make install
> --prefix=/usr/local/packages/mypackage-3.1
> cd<nobr> <wbr></nobr>/usr/local/package
> sudo xstow mypackage-3.1
>
> and to uninstall something:
> xstow -d mypackage-3.1
> rm -rf<nobr> <wbr></nobr>/usr/local/packages/mypackage-3.1
or:
$ sourceinstall mypackage-3.1.tar.gz
and to uninstall something:
$ sourceinstall --remove mypackage-3.1
Re:Source-based is univeral, nothing else really i
Posted by: Stumbles on November 11, 2005 08:55 PM
Not that there's anything wrong with that. IMO it's a decision that should be left up to distro maintainers.
So what a universal installer would have to account for is all the different places applications live, which can and are distro specific including binary and source disrtos.
And what if I wanted to use gcc-4.0.0 instead of 3.4.4 on a source based distro? What then? That one thing and deciding to use glibc with nptl instead of linuxthreads would be a monumental headache for a do all package maintainer.
It would also have to setup a build system for source bases distros. And the build system for Gentoo is not the same as used by Lunar-Linux, which it not the same as used by<nobr> <wbr></nobr>...... another.
It would be a huge monumental task. For what gain? Little that I can see. Not that I'm a distro, um, ahem lady of the evening. But I have used several and find all their package maintainers like urpmi, etc works as advertised. The only real difficulty I've had using them (ones I'm not familiar with) is finding the application name in the GUI menus and perhaps setting up additional repositories.
Right now the only real suggestion I would like to see across all distro and desktop managers is a consistency between menus. That IMO would be more useful.
None of those problems screams to me there should be one universal do all app. This suggestion to me sounds like an obtuse attempt or at least obfuscated attempt to create one distro.
emerge amarok
eventual message: can't find libstdc++.la
Just because it is a source based distribution, that doesn't remove the possibilitites of packaging errors. The<nobr> <wbr></nobr>.tgz raw sources sources are subject to errors in the included configure scripts. Source packaging is just as in need of bug reports as binary packages are.
And mildly defective; If you run the auto-update, it very quickly breaks the ability of the CD installer to function. Dependancy errors make it useless, and can even break other general RPM installs and anything that ends up refering to the CD repositories for dependancies.
I'm kinda considering Redhat Enterprise Linux for my next distro, but not without research, because if EL has these sorts of issues, it's not worth a dime. I'm also considering Linspire, though not just for CNR.
(I'm looking at commercial distros cause I want brain-dead simple, out of the box support for several proprietary technologies. Mostly codec related. On a related note, does anyone know of an MPlayer based browser plugin?)
If an ebuild (text file explaining portage how a package can be build) is not provided with the main tree, you can create one youself, ask or hire someone and put it in an overlay. Overlays are mini-trees you can maintain yourself, or even find on the net for some applications. This may seem complicated at first, but it's going to save you lot's off time in the long run...
So, tough possible, no need to short out portage and compile manualy.
here is an example for a perl module I needed that wasn't in portage:
inherit perl-module
DESCRIPTION="Math::Random"
HOMEPAGE="http://wiki/twiki/bin/view/Labo/Ebuild"
SRC_URI="http://mymachine/mirror/${P}.tar.gz"
SLOT="0"
LICENSE="Artistic"
KEYWORDS="x86 amd64"
IUSE=""
SRC_TEST="do"
In many cases all I have to do is to copy an existing ebuild and change the description!
You are not mentioning yum or smart, and you do not compare to them.
So why is portage better than apt or yum? Where does it has the features where the others are lacking?
And: just solving dependencies is nothing special, yum and smart can do this also.
Sorry, but your article looks just like an article from someone who does not know what he is talking about - but I have to admit that you haven't compared apt to rpm, that's one mistake several people do all the time and which shows that these people has no idea at all...
I only really know apt, but I would have loved to learn more about it's colleagues in the package managing world.
In fact all packages are submitted to the archive as source, and they are then built by the compile farm
That isn't entirely true for Debian. A package is uploaded both as a source archive, and as a binary package.
If the package applies to other architechtures then those will be built from the source. If not the uploaded binary is sufficient.
I believe that in Ubuntu all uploads are source only - but for Debian at least one binary package is uploaded to the repository.
So when I upload a new package, for example, I build it from source on my x86 machine and all other platforms get it built by the <a href="http://buildd.debian.org/" title="debian.org">Debian autobuilders</a debian.org> - but not on x86. The package end users get is the same as the one I built and uploaded.
Does it have binary signing?
Signed binaries?
md5/sha1? cryprographic hashes?
Microsoft has an<nobr> <wbr></nobr>.msi installer, it seems pretty cool.
Can u install portage in a non-gentoo based distribution?
I'll definitely try conary out if you can not use portage in non-gentoo based distributions
<a href="http://0install.net/" title="0install.net">http://0install.net/</a 0install.net>
There's also a comparison matrix here:
<a href="http://0install.net/matrix.html" title="0install.net">http://0install.net/matrix.html</a 0install.net>
I intentionally selected Portage and Conary, because they seem to have a significant following. Portage is the de-facto pioneer in distributed package management in Linux distros.
Sure, some package manager following the same paradigm predated portage, however they have not been adopted by many in the community. Yum for example has no major distribution backing it.
Conary on the other hand has distributions such as Foresight and rPAth which have been consistantly gaining ground.
About the ebuild thing, I thank the reader for pointing out a mistake in the article and filling a gap in my knowledge,
However this article was written with average desktop users in mind who would not go to such lengths as create their own ebuilds.
Irfan Habib
HowTo: GENTOO 2005.1 INSTALLATION SCRIPT/WALK-THRU
Posted by: Anonymous Coward on November 11, 2005 11:50 AM& JAVASCRIPT MOVIES.
Interested in a script to walk you through a Gentoo Linux installation? Then click here:
<a href="http://linux.coconia.net/" title="coconia.net">http://linux.coconia.net/</a coconia.net>
Even if you do not use the scripts the information on this page will make the installation much easier.
Links to the scripts can be found at the bottom of the page.
I would be interested in any errors that anyone may find.
There is also code for JAVASCRIPT MOVIES (and a couple to watch).
About yum: well, I would call Fedora, which is completly setting up on yum, a larger distribution. I dont't think that even Foresight and rPath together has a user base which is as big as the Fedora/Red Hat user base...
Others, like CentOS and Scientific Linux, which are derivatices of Red Hat Enterprise Linux, are using yum, too.
So: Although I see that, for example, yast, yum and urpmi are not able to build from source (what is not option for a averare computer user, by the way), I do not see the other advantages of these described tools.
Are they able to use mirror-lists like yum and smart? How can they work against the often called "dependency hell" which comes up when two developers start to submit the same package to different repositories?
Questions and questions...
"Anyone responsible for system maintenance or system configuration wants to accomplish their tasks in the simplest and safest manner. Traditional packaging systems make loading a new release of an application or library easy, but do so in a "blanket" manner. When traditional systems update packages, they have no regard for determining whether the files being replaced are pristine or not. Changes are simply overwritten whether the file has been changed or not. Writing unchanged files over again creates greater overhead and is intrusive to a well-running system. The risk is normally small, but the overhead is significant.
Just as source code control systems use patch files to describe the differences between two versions of a file, Conary uses changesets to describe the differences between versions of components. These changesets include the actual changes in contents in existing files, the contents of new files, name changes (if files are renamed but otherwise unchanged, only the change in name is included), permissions changes, and so forth. They also can include changes to components as well as to individual files.
Conary changesets are quite often transient objects; they are created as part of an operation (such as fetching a new version from a repository) and disappear when that operation has completed. They can be stored in files, however, which allows them to be distributed like the package files produced by a classical package management system. Applying changesets rather than installing whole new versions of libraries and applications allows Conary to update only the parts of the system which have changed, rather than blindly reinstalling every file. Changesets are more efficient than classic packages in at least two ways: they take less space to express what changes to make on the system, and they take less time to apply the changes to the system when the set of changes required is small. These benefits apply whether the changesets are acquired through a network connection to a repository, on a CD, or via any other method.
Representing updates as changesets not only saves space and bandwidth, it also allows merging. Conary intelligently merges changes to file contents and file metadata such as permissions. This capability is very useful if you wish to maintain a branch of an application or library while keeping current with vendor maintenance, while adding a couple of patches to meet local needs.
Conary also preserves local changes in essentially the same way. When, for example, you add a few lines to a configuration file on an installed system, and then a new version of an application is released with changes to that configuration file, Conary can merge the two unless there is a direct conflict (unusual, but possible). If there is a conflict, it is marked as such so that modifications can be applied. Also, if you change something as simple as a file's permissions, those changes will be preserved across upgrades.
A local changeset is a special changeset that represents the changes made on a local system. There are two ways Conary allows you to commit local changesets: committing a local changeset to a repository, and distributing the changeset to individual systems. The first is better for systems with entirely centralized management policies, and the latter for individual systems that are expected to autonomously update themselves asynchronously.
Changesets represent a sane approach to preserving changes to a system while ensuring system integrity and limiting resources used to make such changes. System customization and maintenance are no longer an obstacle with Conary."
You have the same idea behind it that you don't have to install everything new just for a few codeline updates, you jsut download a delta-rpm which will only update what's needed.
And the local changes are handled by rpm itself - if it comes with new configuration files it does not overwrite the oled one, but creates a failsafe of the new one (not sure in which cases of the new or of the old one).
So, it's a nice idea, but it's not something which is unique in the linux world...
But we are getting into an area where you can hardly blame an author for not knowing everything - there are only a few people who have the knowledge to compare all the package systems out there. But the author should be aware of this fact, too...
So it's not the best way to talk about "limited" package managers when I am not sure what these limitations are about...
HowTo: GENTOO 2005.1 INSTALLATION SCRIPT/WALK-THRU
Posted by: Anonymous Coward on November 11, 2005 12:02 PM& JAVASCRIPT MOVIES.
Interested in a script to walk you through a Gentoo Linux installation? Then click here:
<a href="http://linux.coconia.net/" title="coconia.net">http://linux.coconia.net/</a coconia.net>
Even if you do not use the scripts the information on this page will make the installation much easier.
Links to the scripts can be found at the bottom of the page.
I would be interested in any errors that anyone may find.
There is also code for JAVASCRIPT MOVIES (and a couple to watch).
Pacman is the binary manager, and it works like conary/apt. It resolves all the deps and other fancy things, and it's really easy to use.
If you prefer source builds, there's ABS (the Arch Bukld System) that works just like portage: you update the tree and recompile the packages you want with only one command, makepkg. Your rebuilt packages perfectly integrate in your system, like emerged ones.
For more infos: <a href="http://archlinux.org/pacman/" title="archlinux.org">http://archlinux.org/pacman/</a archlinux.org>
O. Wyss
PS. See also "<a href="http://wyodesktop.sf.net/index.php?page=pkgdist.html" title="sf.net">http://wyodesktop.sf.net/index.php?page=pkgdist.<nobr>h<wbr></nobr> tml</a sf.net>"
A lot of open source projects just get released as unprepared source code, leaving users the deal with all the dependancies and often don't even go through an optimization stage, expecting everyone else to buy a new computer again.
Windows software has dependancies too, but they know what libraries come with the operating system, and include the ones that don't. They've solved this problem and it's a relatively simple system.
1) They know what's in the system.
2) They include what isn't.
This is seperate from most OSS projects, which goes like this;
1) They have no idea system it'll be run on or what's in it. There is no set of packages which can be expected to exist.
2)<nobr> <wbr></nobr>...There is no 2.
People think the LSB is supposed to solve #1, but it doesn't do a thing for that. Frankly, I'm not even sure what it's for or if anyone gives a damn what they're up to.
Most users are way better off without emerge, but with the traditional tools. Especially Debian and Ubuntu are fantastic for just about every user.
A typical user might not even install any new software but just stick with what he had installed in the first round.
A typical user might not even install any new software but just stick with what he had installed in the first round.
A typical computer user uses Windows XP. Does that make it a good OS?!
Roumen.
I find packages that fail to install on FC4 that are ~specially built~ for FC4.
Plus running the updator makes the whole package system break.
That said, typical users install programs all the time.
Most people like to, you know, actually do things with their computer, not just poke at it and try to make it run faster.
Emerde is a port of Portage to Slackware, and even integrates with the native package manager. i'd strongly suggest installing ONLY the base packages before installing Emerde, because it's scripts for eyeing all previously installed packages aren't entirely up to speed, but otherwise it works.
check it out:
<a href="http://emerde.freaknet.org/" title="freaknet.org">http://emerde.freaknet.org/</a freaknet.org>
have a gander:
autopackage.org
variable definitions (including DEPENDencies) and maybe some overloaded functions.
If an ebuild exists it can be added to a portage overlay and from that point on it will be handled by emerge. It is also fairly easy to create ebuilds for simple packages. (KDE doesn't fall into this catagory though.)
One of the other great things about portage our the little helper apps like revdep-rebuild that searches for programs that are linked against other packages that may have been updated or removed. This tool will find and rebuild all of those programs/packages.
But the greatest thing about Gentoo is the fact that it is a live system. Nobody with a functional Gentoo install cares when a new version comes out. If they keep their systems upto date there is absolutely no reason to ever reinstall an updated version of Gentoo again. This does complicate some things like the recent Apache and MySQL updates but it is worth the occasional hassel for a system that is always current.
In response to other comments: It does have package signing for the sorce tar balls. Although you can't interact with Gentoo's remote tree other than to sync against it, once that is done the tree can then be shared with many other systems via nfs and emerge can even be coaxed into building binary packages for deployment on other sytems of like configuration. And to those that think there is a one-size-fits-all approach out there similiar to Microsoft's: sorry. GNU/Linux is a constantly evoloving system and as such many things are in a constant state of flux. To have a standard that developers could write to would involve having a code freeze for GNU/Linux/X/Gnome/KDE/E/etc... and a long shake out period. This is contrary to the way in which FOSS is developed. A program written against all of the newest libraries won't work until people get upgraded and if it is written to be compatible with older libraries it will be out of date upon release or shortly thereafter.
RiverRat
Gentoo.org and
irc://irc.Freenode.net #gentoo
1. A system that need never be re-installed but still runs the latest & the greatest
2. Flexible packaging system that allows me custom USE flags for every single one of my packages if I wanted, package dependency system that doesn't bog me down to the ground because some little silly package wanted some particular other package for no obvious reason but because the packaging database said so.
3. Slots. Gentoo allows me KDE 3.4 & KDE 3.5 on the same system! How cool is that?!
I hate enjoying my linux box just to find out that soon I need to wipe out everything because NextLinuxVersion x.xx.x has come out and my system doesn't have all the cool stuff the new one has.
I have a lot of custom scripts and all kinds of setups that run on my system and do different things. Reinstalling a new system is so much hassle to me that I will give anything to not do it. Fortunately with Gentoo I don't have to give up much. Just a little time in the beginning when all packages compile. As soon as the initial gentoo setup is complete gentoo maitenance is as much as any other Linux distro.
Gentoo has a few weaknesses:
1. Slow start time - it can take hours and even days to install Gentoo with all the blows and whistles on it compared to other distros where it could take as little as 30 mins. Last time I installed gentoo on my desktop I wanted some serious software like KDE & Gnome. KDE alone took me about 2-3 days to compile. Gnome is a little better. But you know what? I don't regret it because now that I have it all I do is run my updates at night and when I get up in the morning I wake up to a new KDE/Gnome/whatever. Last time I wanted to upgrade from KDE 3.4.1 to 3.5.2. and it took me about 2-3 days to install the new version but it all ran on a terminal while I was using all my old kde programs so I wasn't sitting there at the black screen waiting on gentoo to finish it all so I could use Kmail or Gimp. This is because Gentoo has something called SLOT's that will let you install more than one version of a software concurrently. I have yet to see a distro that has that.
Gentoo is not a system for the average programmer-joe that shows no interest in building a system that can last them for a long time and just likes to pop their cd in and have it all running in less than an hour. Gentoo is for people who like to poke around, research, spend time understanding how the system works. Gentoo is a distro for long-term use.
Roumen Semov - semovrs _at_ concord _dot edu
P.S. Some may wonder - how come Gentoo doesn't have OS versions like other standard linux distros. My answer is: because Gentoo is extremely flexible. Gentoo's versioning system is blurry or almost nonexistent because the packages installed do not define the OS nor vice versa, this is how flexible Gentoo is.
Its basically superflous for EL since the system-config-packages is also updated and available from RHN for every major update and you can get media kits including those versions.
For future updates, you are relying on up2date anyway. EL is worth the dime you provide for the all the certifications (hardware and ISV), support etc and not for its package management capabilities which arent nothing bad either
Many times we isntall software that we don't want to have to wait for, and its not always possible to use up2date during kickstart installs (especially on a network that might not have internet access).
We've set <a href="http://smartpm.org/" title="smartpm.org">smart</a smartpm.org> up for our network installation media for RedHat, and also for our custom software yum repo, and now only use RHN/up2date for updates (not for installing additional packages).
Smart supports all the major repo formats, including the hdlists on the RHEL media, and is present in a number of rpm-based distributions and Ubuntu.
The emerge --search tool in itself is worth the wait
Guess you missed apt-cache search, and haven't tried Mandriva (urpmq/urpmf).
So, I can't take this conclusion seriously:
I find Portage to be the best Package Management system I've used to date
And I mean this is a very, very specific way;
First, a standard set of libraries and naming conventions for a desktop (other contexts would have different standard sets) would be defined.
Then distributions targeting the desktop (or other given standard set) would include those libraries as a minimum.
Software developers working with the standard would statically link dependancies not in said standard.
The standard would include things like GTK, QT, Gnome support, KDE support, SDL, etc. basically enough that unreasonable things wouldn't have to be statically linked.
But if, for example, a program requires an obscure library for panoramic image processing, something about one in a million Linux users are likely to need, it would be statically linked.
That would greatly simplify everything, and make it so you don't even need an automated dependancy downloader.<nobr> <wbr></nobr>...Opinions? Is such a thing worth developing? I think it would kinda solve the problem at it's source, instead of these glue-on-top bandaid solutions like apt, yum and cnr.
<a href="http://www.sourcemage.org/" title="sourcemage.org">http://www.sourcemage.org/</a sourcemage.org>
The emerge --search tool in itself is worth the wait whilst watching Gentoo compile!
problems?! what problems?!?!?!
Posted by: Anonymous Coward on November 11, 2005 04:39 AM#