users are not aware that xz-devel is outdated and they should replace it by xz

[vinc17@…]

There's no reason that users should remain with xz-devel 4.999.9beta_0 instead of installing xz 5.0.0_0, and they cannot be aware of this new version with "port outdated".

[afb@…]

This is the same for all pre-release "development" ports that the user has chosen to install.

[afb@…]

But since someone already added explicit conflicts, why not add replaced_by too ?

[ryandesign (Ryan Carsten Schmidt)]

Sure, I added conflicts indicators, because the ports do conflict. :) If you'd like instead to mark xz-devel as replaced_by xz, that would be a fine thing to do.

[afb@…]

Fixed, r74169.

[afb@…]

Pretty much all the development ports conflict with their stable counterparts, so adding explicit conflicts is somewhat redundant especially if they already have implicit file conflicts. But it's a pretty strange way to version things, either way.

[ryandesign (Ryan Carsten Schmidt)]

Replying to afb@…:

Fixed, r74169.

Also, the version needs to be increased, and users need to be prevented from attempting to install the port, and all the lines relating to installing the port can be removed. r74172.

Replying to afb@…:

Pretty much all the development ports conflict with their stable counterparts,

Yes they do.

so adding explicit conflicts is somewhat redundant

Adding explicit conflicts is absolutely necessary; it prevents a user from wasting time building a port if it won't be able to activate anyway due to conflicting files.

especially if they already have implicit file conflicts.

Which implicit file conflicts are you talking about?

But it's a pretty strange way to version things, either way.

What is?

[afb@…]

so adding explicit conflicts is somewhat redundant

Adding explicit conflicts is absolutely necessary; it prevents a user from wasting time building a port if it won't be able to activate anyway due to conflicting files.

Well, it does activate if the new/stable one is deactivated.

especially if they already have implicit file conflicts.

Which implicit file conflicts are you talking about?

Your "conflicting files", above. As in they both install bin/xz

But it's a pretty strange way to version things, either way.

What is?

Separating two versions of a piece of software by changing name.

Upgrading from 4.999.9beta to 5.0.0 is more of a "version" thing ?

So ports systems are pretty strange, that way. Not everything is.

I have no idea how the new xz-devel works, so I'll unmaintain it.

[ryandesign (Ryan Carsten Schmidt)]

Replying to afb@…:

Adding explicit conflicts is absolutely necessary; it prevents a user from wasting time building a port if it won't be able to activate anyway due to conflicting files.

Well, it does activate if the new/stable one is deactivated.

Which implicit file conflicts are you talking about?

Your "conflicting files", above. As in they both install bin/xz

That's the exclusive purpose of the conflicts keyword -- to identify ports that want to install the same files. The ports system assumes only one port will ever install any particular file; the conflicts keyword is the mechanism by which ports can be tagged to override this assumption, to provide a better user experience.

But it's a pretty strange way to version things, either way.

What is?

Separating two versions of a piece of software by changing name.

Upgrading from 4.999.9beta to 5.0.0 is more of a "version" thing ?

So ports systems are pretty strange, that way. Not everything is.

Well, 4.999.9beta was a development version. 5.0.0 is a stable version. In cases where we want to maintain both a development version and a stable version of a software in MacPorts, we maintain separate foo-devel and foo ports. c.f. php5 & php5-devel, graphviz & graphviz-devel, pango & pango-devel, cairo & cairo-devel, libpixman & libpixman-devel, glib2 & glib2-devel, minivmac & minivmac-devel, etc. In the case of xz, we have the more unusual circumstance of having had a development version of a port before, and wishing to discontinue it and replace it with a stable version, so we have to go through some acrobatics to support that.

I have no idea how the new xz-devel works, so I'll unmaintain it.

It works in these ways:

• replaced_by tells MacPorts that when a user tries to upgrade the port, it will instead install its replacement.
• increasing version causes the old port to appear in the output of "port outdated", thus prompting the user to run "port upgrade" and initiate the above process.
• clearing distfiles makes "port fetch" not attempt to download anything.
• since there are no distfiles and the port doesn't install anything anymore, master_sites, checksums, patchfiles, dependencies, configure, build and destroot arguments, variants, and conflicts are deleted
• a message is printed in pre-configure so that anyone attempting to install the port will be informed of its replacement.
• livecheck.type is set to none since this port's version never needs to be updated again.

Once all users can reasonably be expected to have run "sudo port sync" and "sudo port upgrade xz-devel" (to cause xz-devel to go away and xz to be installed in its place), xz-devel can be deleted. I typically recommend this not be done until at least one year in the future, since some users upgrade very infrequently.