Getting to know your portmgr@ — Joe Marcus Clarke

October 21, 2013 by · 3 Comments 

This is the start of an ongoing series profiling members of the FreeBSD Ports Management Team.  In this interview, we talk to longest serving member of the team, Joe Marcus Clarke, aka marcus@

Name

Joe Marcus Clarke

Committer name

marcus

Inspiration for your IRC nick

Longish story. Marcus is not my middle name. It’s Michael. When I was
seven, I came up with the nickname myself. I thought it sounded cool.
And there you go.

TLD of origin

US

Occupation

Distinguished Services Engineer at Cisco Systems

When did you join portmgr@

Damn, I don’t remember. My email dates
back to 2006, but I think it was before that…

Blog

Nope

Inspiration for using FreeBSD

Another longish story. I was in college at University of Miami (go
Canes!), and I managed to procure an old x86 PC. We were going to
install Linux on it. I thought having a csh in my own dorm room was
just awesome. A friend ran into my room and said I needed to check out
this thing called, “FreeBSD.” Sure, what the hell. A few days and
about 50 floppy disks later, I was sold. I never looked back.

Who was your first contact in FreeBSD

sobomax (Maxim Sobolev)

Who was your mentor(s)

sobomax

What was your most embarrassing moment in FreeBSD

Probably the first time I broke INDEX, or my first release song, “Ports
Freeze Baby.”

Boxers / Briefs / other

boxers

What is your role in your circle of friends

What are friends?

vi(m) / emacs / other

VIM (what is this “emacs” thing you speak of?)

What keeps you motivated in FreeBSD

I really believe it is the best operating system around. I advocate it
passionately at work (to the point people thought I got paid to say,
“FreeBSD”). I look for any chance to install it. I love it when people
run network tests to my servers at work and comment how amazing the IP
stack is… :-)

Favourite musician/band

I like a lot of musical types, but I’m particular to metal. I’m into
Five Finger Death Punch now.

What book do you have on your bedside table

Print is dead. But I’m reading up on Python online now. when is
Stackoverflow going to publish a book?

coffee / tea / other : Diet Pepsi

Do you have a guilty pleasure

Call of Duty

How would you describe yourself

Alive

sendmail / postfix / other

sendmail

Do you have a hobby outside of FreeBSD

I’m learning to be a pilot.

What is your favourite TV show

I loved House. I thought it was the closest thing on TV to be a network
troubleshooter. Right now, I’m big into Strike Back.

Claim to Fame

Tinderbox, I guess

What did you have for breakfast today

I only eat once per day. Usually at night.

What sports team do you support

University of Miami Hurricanes and Manchester United

What else do you do in the world of FreeBSD

GNOME, Netatalk, wireshark, Tinderbox, and a lot of local sysadmin stuff.

What can you tell us about yourself that most people don’t know

My North Carolina license plate reads, “FREEBSD”.

Any parting words you want to share

What am I, your priest?

What is your .sig at the moment

It’s lame. Don’t ask :-)

Package name collisions

October 3, 2013 by · Leave a Comment 

For the sake of being able to have clean working binary packages, pkgng has had to use a dirty hack: origin is used has an identifier instead of the package name.

Why: How to determine than ImageMagick-nox11 and ImageMagick are the same package? and if I don’t know they are the same package how to upgrade them properly? same goes how the package manager can know that mysql-client-5.2.1 is not an upgrade of mysql-client-5.0.1?

How can pkgng determine which subversion is the right version to use: ‘pkg install subversion’ will propose all possible subversion, in that case the higher version is probably the default version, but in perl case, the higher version is probably not the one you want.

Some packages are totally different project but have the same package name… How can pkgng differenciate them?

So please stop using LATEST_LINK to differenciate the different port but directly make _unique_ package names, pkgng will switch back to package name as soon as possible (that will also solve the ugly and stupid pkg set -o).

There is multiple possibility to make sure to properly handle multiple versions of packages:

  1. suffix everything with part of the version (like tcl)
  2. suffix everything but the default with part of the version
  3. have only 2 or 3 different version: project-legacy project project-devel

Please stop renaming the packages based on options! Options are now registered with the package with both pkgng and pkg_install, please stop adding suffix base on options!

Think about the end user, he will try to install a package, it should be as transparent for him as possible.

I is really important to change that as quick as possible. This page on the wiki reference all the port with conflicting names.

Staging

October 3, 2013 by · Leave a Comment 

You may has notice that staging has hit the ports tree, staging is something really important, all packages system are using that feature for eons, sometime called DESTDIR sometime called FAKEDIR.

Staging is consistent in adding a new step while building packages: install everything into ${STAGEDIR}. Then we can directly create packages out of that directory without having to install into /. What the implementation does is:

With pkg_install (legacy package tools):

  • Create a package from the stage directory
  • Install that package.

With pkgng:

  • Create a package from that stage directory

OR

  • Install to / (pkgng can consider the stage directory as if it is a package)

What it means is, that it is the end of the bad plist, only things in plist are really installed, this is the end of the broken packages that break the system because they fail in the middle of make install as a package will only be installed once we are sure the build process properly pass.

It allows right now to build and create a package without the need to be root.
It gives us new targets:

  • make makeplist (to create the pkg-plist)
  • make check-orphans (to print what is in the stage directory but not in pkg-plist)

It reduces code duplication: in the end the installation is being done via a package installation meaning that PKG-MESSAGE is automatically printed, all pre/post installation scripts are executed.

It reduces patches: no need anymore to patch upstream Makefiles to avoid installing the DOCS just do not list them in pkg-plist or conditionnaly list them in the pkg-plist.

This also allows lots of new features to come:

  • Allow to create sub-packages
  • Allow to create debuginfo packages
  • Allow to do a lot of sanity check in the staging area to improve our QA

To convert your ports refer to: https://wiki.freebsd.org/ports/StageDir

Along with stage you have noticed that MAN* and MLINKS has gone, and now all the manpages should be added to the plist. BTW MANCOMPRESSED is also not necessary now.

There is 3 reason behind making it go and not being replaced:

  1. The initial goal of those macros was to be able to compress the right manpages and to handle the different hardlinks/symlinks between those pages. Because it was directly installed in / rather than using a stage directory, it was necessary to at a point list them. and to properly track the different links in MLINKS (which wasn’t done properly in most ports btw :)). With stage, we have a new compress-man which does it properly on its own without the need to get the list of the manpages, without the need of an explicit declaration of the links. This syntax to handle localized man pages was also terrific :) and if you have a port mixing manpages in “non regular” and “regular” localtion, it was totally messing
  2. Consistency, a port is basically: some metadata, a plist and some operations to perform. for metadata all metadata are in the Makefile, all operations are in the Makefile but plist can be a mix of pkg-plist and Makefile, this is inconsistent, it makes sometime hard to figure out why a file has been added to the plist etc. Also this makes us having tons of targets define to handle those extras entries and results in highly inefficient make(1) usage.
  3. Stage is also a first step to go to sub-packages, sub-packages will basically be: 1 port able to produce N packages, to be able to do this we will use multiple plist, having the files properly defined already in plist will help that. Having files defined in macros on Makefile will make it hard todetermine which one should go in which plist.

Last thing I would like to add about it: I don’t see the difference personnaly between listing N lines of manpages into Makefile MAN* macros where btw you have to manually define the categories where to put them and adding those N lines
directly into the plist where make makeplist and/or make check-orphans can help you getting the exact lines automatically?

Ports Slush is now in over

April 22, 2013 by · Leave a Comment 

Just to make it official, the ports slush is over.

Ports committers are now able to perform regular updates, business as usual, no need for portmgr@ approvals.

You can read more at http://lists.freebsd.org/pipermail/freebsd-ports-announce/2013-April/000058.html

Ports Slush is now in effect

April 16, 2013 by · Leave a Comment 

Just to make it official, the ports hard freeze has been lifted.

Ports committers are now able to perform regular updates, just no sweeping
commits without prior approval from portmgr. This period of slush will
continue until 8.4 is out the door.

Read more at http://lists.freebsd.org/pipermail/freebsd-ports-announce/2013-April/000056.html

FreeBSD Ports tree has been tagged with RELEASE_7_EOL

March 6, 2013 by · Leave a Comment 

The FreeBSD Ports Management Team wishes to remind users that February 28 was the end of support for the Ports Collection for both FreeBSD 7.4 RELEASE and the FreeBSD 7.x STABLE branch. Neither the infrastructure nor individual ports are guaranteed to work on these FreeBSD versions after that date. A tag has be created for users who cannot upgrade for some reason, at which time these users are advised to stop tracking the latest ports repository and use the RELEASE_7_EOL tag instead.

Read more at http://lists.freebsd.org/pipermail/freebsd-ports-announce/2013-March/000051.html

linimon steps down from portmgr

February 21, 2013 by · 1 Comment 

Mark Linimon, aka linimon@,  recently stepped down from his duties on the FreeBSD Ports Management Team.

Mark joined the team back in 2004, providing nine years of continuity to the Ports Infrastructure.  Among the many things Mark did, was maintaining and documenting the current portbuild system that the team uses for -exp runs and package building.  With his other bugbuster@ hat on, he played middle man contacting maintainers of BROKEN and DEPRECATED ports.

On behalf of the Ports Management team, we would like to thank Mark for his many years of service and dedication, his contributions will be greatly missed.

 

Thomas

on behalf of portmgr@

FreeBSD 9.1 ports freeze is officially over

December 9, 2012 by · Leave a Comment 

Just to make it officially official, the ports feature freeze has been lifted.

Ports committers are now entitled to perform sweeping commits. Keep in mind that -exp runs are always a good idea if you think there is a significant change to the ports tree.

And just remember, PLEASE TRY TO NOT BREAK THE INDEX!

Thomas
on behalf of portmgr@

decke@ joins portmgr@

October 19, 2012 by · Leave a Comment 

The FreeBSD Ports Management team is pleased to welcome Bernhard Froelich, aka decke@, to it’s ranks.

Bernhard was a long time ports contributor, and received his ports commit bit back in March 2010.

More recently, Bernhard was the one responsible for bringing us Redports.org shared tinderbox.

Please join me in welcoming decke@ to the team.

Thomas
on behalf of portmgr@

Ports Feature Freeze for 9.1

October 10, 2012 by · 2 Comments 

FreeBSD 9.1 RC2 has been pulicly announced, it is now time for the the Ports Feature Freeze.

Normal upgrade, new ports, and changes that do not affect other ports will be allowed without prior approval, but with the extra

Feature safe: yes

tag in the commit message. Any commit that is sweeping, that is, touches a large number of ports, infrastructural changes, commits to ports with unusually high number of dependencies, and any other commit that requires the rebuilding of many packages will not be allowed without prior explicit approval from portmgr@.

Check out http://www.freebsd.org/portmgr/implementation.html#sweeping_changes for what constiutes a sweeping change.
Thomas
on behalf of portmgr@

« Previous PageNext Page »