Prev: Newer autoconf (2.63+)?
Next: Silent distfiles conflict between graphics/xface.el andmail/x-face-e21.
From: Ivan Voras on 29 Mar 2010 11:57
Hi,

First of all, I'd like to have this particular discussion in the open
with ports developers and maintainers. So please - if you are a "simple"
user, without a port to maintain, you will be given another thread if
anything comes out as a result from this discussion.

There is a discussion[*] currently in The Forbidden Palace about the
possibility (it's just that - a discussion of viability) of having a
"stable" ports branch which would in the future as a consequence enable
building binary packages and deploying them in the way of Linux's "apt"
and "yum" tools.

One way to do it, my proposal, would be to maintain a stable "overlay"
of the ports, one for each major supported branch (i.e. 6.x, 7.x, 8.x),
containing ports deemed "important" for some reason.

Some more potential properties:

* Ports in the stable branch/overlay would be maintained with more
rigorous checking.
* Updates which break shared libraries would not be allowed within such
a branch/overlay (i.e. no updating gnome 2.xx to 2.x(x+1), libpng,
libjpeg, xorg).
* Binary packages for a whole X.Y branch would be built on X.0 (e.g. on
7.0 for all 7.x branches).

This is obviously pretty fuzzy - rules would need to be specifically
made later.

The biggest problem would seem to be the burden this would have on ports
developers vs the gains that could be gotten from this system.

In some cases the burdens are obvious - the maintainer(s) would need to
e.g. maintain three versions of the ports - a random example would be
e.g. X.Org 7.0 for 6.x, 7.2 for 7.x and 7.4 for 8.x. Another would be
keeping PHP 5.2 for 7.x and 8.x and having 5.3 in the future
(CURRENT/9.x) branch.

Some of the benefits are also obvious. The scheme would allow faster and
more convenient updating of the system, without breakage of shlibs
within a branch.

Within all this, I think one point is important: there should be no
inventing of wheels or pioneering work on this. Much the same concepts
are already proven to work with Linux systems (stable package branches,
apt and yum), so this is not very much unknown territory. Here not be
dragons :)

I consider this just an opinion-collecting thread: Would you, as a
maintainer / developer, be interested in something like this, and why?





[*] the discussion was started unexpectedly following my post bringing
http://blog.hagander.net/archives/167-PostgreSQL-infrastructure-updates.html
to attention.

_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Alexey Shuvaev on 29 Mar 2010 13:27
On Mon, Mar 29, 2010 at 05:57:04PM +0200, Ivan Voras wrote:
> Hi,
>
> First of all, I'd like to have this particular discussion in the open
> with ports developers and maintainers. So please - if you are a "simple"
> user, without a port to maintain, you will be given another thread if
> anything comes out as a result from this discussion.
>
To start with, the number of ports I maintain is not large at all,
and all of them are mostly "dark corners" never used.

> There is a discussion[*] currently in The Forbidden Palace about the
> possibility (it's just that - a discussion of viability) of having a
> "stable" ports branch which would in the future as a consequence enable
> building binary packages and deploying them in the way of Linux's "apt"
> and "yum" tools.
>
> One way to do it, my proposal, would be to maintain a stable "overlay"
> of the ports, one for each major supported branch (i.e. 6.x, 7.x, 8.x),
> containing ports deemed "important" for some reason.
>
What is the criteria which port version goes into particular branch?
That is, which versions of, say, gtk will have 6.x, 7.x and 8.x?
Is it supposed to be what was available at the time when the branch
was out?

If this is the case, 6.x branch will have pretty outdated
"heavy infrastructure" ports (like gnome/kde libs, see below).
What if the supported lifetime of the port upstream is less than
supported lifetime of FreeBSD branch? Who will backport at least
security fixes to the port?

> Some more potential properties:
>
> * Ports in the stable branch/overlay would be maintained with more
> rigorous checking.
>
Are the current ports not already rigorously tested? :)

> * Updates which break shared libraries would not be allowed within such
> a branch/overlay (i.e. no updating gnome 2.xx to 2.x(x+1), libpng,
> libjpeg, xorg).
>
On the one side who will maintain such a beasts like outdated version of
xorg??? On the other side, if all major ports are "frozen" what is left
to be updated? In other words what is the difference between proposed
"stable" ports branch and a static snapshot?

> * Binary packages for a whole X.Y branch would be built on X.0 (e.g. on
> 7.0 for all 7.x branches).
>
Could not this be done already with the current ports?

> This is obviously pretty fuzzy - rules would need to be specifically
> made later.
>
> The biggest problem would seem to be the burden this would have on ports
> developers vs the gains that could be gotten from this system.
>
> In some cases the burdens are obvious - the maintainer(s) would need to
> e.g. maintain three versions of the ports - a random example would be
> e.g. X.Org 7.0 for 6.x, 7.2 for 7.x and 7.4 for 8.x. Another would be
> keeping PHP 5.2 for 7.x and 8.x and having 5.3 in the future
> (CURRENT/9.x) branch.
>
> Some of the benefits are also obvious. The scheme would allow faster and
> more convenient updating of the system, without breakage of shlibs
> within a branch.
>
> Within all this, I think one point is important: there should be no
> inventing of wheels or pioneering work on this. Much the same concepts
> are already proven to work with Linux systems (stable package branches,
> apt and yum), so this is not very much unknown territory. Here not be
> dragons :)
>
I have not used Linux myself in the last 6 years, so I'm not very
confident with all these 'apt', 'yum' and co, however I have 2 Ubuntu
installations not far from me. Well, as tools they (apt, ...) may be
quite good, but I remember the too early update to firefox3
(which crashed every few minutes and that was an official gnome browser!)
and the problems with intel video card (hard freeze of the system)
after upgrade to the new Xorg. So, the tools alone do not solve
that many problems...

> I consider this just an opinion-collecting thread: Would you, as a
> maintainer / developer, be interested in something like this, and why?
>
Weighting these all, I would say no. There is already enough fun keeping
ports working on CURRENT. And see below.

> [*] the discussion was started unexpectedly following my post bringing
> http://blog.hagander.net/archives/167-PostgreSQL-infrastructure-updates.html
> to attention.
>
Quoting:
"... that will ensure that all our machines look the same way.
This also plugs into our monitoring systems very well,
making applying (security) updates across the many machines much easier. ..."

It's a pity that pgsql devs are not familiar with ports-mgmt/tinderbox...
Looks like it is exactly what they need. Maybe the README from tinderbox
deserves the place in the handbook
("Preparing packages in corporate environment" or something similar)?
Compiling the set of possibly customized (patched) packages for further
deployment on a large number of machines is an easy task when using
tinderbox.

Back on topic, would not it be better to provide "official packages for
upgrades" built from some chosen snapshots of the ports tree?
Then some community (portmgr?) would shape the flow of updates to the tree,
blocking the "sweeping changes" (and allowing all others?) during preparation
of the "snapshot points"? Something similar is already done during
releases. Updating one ports while holding the others sounds more like
repository manipulation rather than a real maintainance of different branches.
In some cases (when really needed?) there are already different variants
of the same port (port / portXY / port-devel).

Alexey.
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Doug Hardie on 29 Mar 2010 13:41

On 29 March 2010, at 08:57, Ivan Voras wrote:

> In some cases the burdens are obvious - the maintainer(s) would need to
> e.g. maintain three versions of the ports - a random example would be
> e.g. X.Org 7.0 for 6.x, 7.2 for 7.x and 7.4 for 8.x. Another would be
> keeping PHP 5.2 for 7.x and 8.x and having 5.3 in the future
> (CURRENT/9.x) branch.

I am a bit concerned about your concept of maintain, being able to build a port successfully, does not necessarily mean it will work properly. For example, qpopper (which I maintain) has an issue where one feature does not work properly on 64 bit machines where it works fine on 32 bit machines. In addition, there are a number of other machine types that are currently not heavily used but might become so in the future. Thats a lot of different combinations of hardware and OSs to keep running for the maintainers. _______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Ivan Voras on 29 Mar 2010 14:35
Alexey Shuvaev wrote:

>> One way to do it, my proposal, would be to maintain a stable "overlay"
>> of the ports, one for each major supported branch (i.e. 6.x, 7.x, 8.x),
>> containing ports deemed "important" for some reason.
>>
> What is the criteria which port version goes into particular branch?
> That is, which versions of, say, gtk will have 6.x, 7.x and 8.x?
> Is it supposed to be what was available at the time when the branch
> was out?

I'd suggest that yes - keeping the current ports tree as-is as the
"unstable" "HEAD".

> If this is the case, 6.x branch will have pretty outdated
> "heavy infrastructure" ports (like gnome/kde libs, see below).

Yes. Exactly as with all other operating systems with long-term support
and binary packages. OTOH, users can always track HEAD as they do now.
Only the users who really need it would follow the "stagnating"
branches. See ref: Debian :)

Also, nothing (for some values of "nothing") would stop people running
FreeBSD 6.x to track the 7.x stable ports branch if they want. Or not,
depending on ports developers.

> What if the supported lifetime of the port upstream is less than
> supported lifetime of FreeBSD branch?

Only if an update is needed (e.g. for security purposes), either of these:

1) Some other OS, Linux distribution, etc. nags the developers to fix it
upstream or do the patch themselves, which we can pick up
2) The port maintainer(s) do it themselves (discouraged, of course)
3) The port is marked as insecure (possibly in vuxml) and the users are
left to nag the developers for #1 or #2 :)

If there is no immediate pressing need to update such a port (e.g.
security), people can run arbitrarily old versions of applications
forever. Or track HEAD.

> Who will backport at least
> security fixes to the port?

I'd suggest that, previously to including the port in the "stable"
branched the maintainer(s) agree to do it if necessary. Of course, it
would be completely voluntarily - no maintainance, no stable port. It
would defeat the purpose.

>> * Updates which break shared libraries would not be allowed within such
>> a branch/overlay (i.e. no updating gnome 2.xx to 2.x(x+1), libpng,
>> libjpeg, xorg).
>>
> On the one side who will maintain such a beasts like outdated version of
> xorg??? On the other side, if all major ports are "frozen" what is left

Outdated beasts tend not to change much.

> to be updated? In other words what is the difference between proposed
> "stable" ports branch and a static snapshot?

The static snapshot doesn't magically evolve Apache from 2.2.0 to
2.2.14+ but deliberately stays away from 2.4.0 because it would break
its ABI and require recompilation of its modules :)

As others noted, shared libraries are the issue - if a port, during its
update, bumps its shared library version (libsomething.so.1 ->
libsomething.so.2), it would *not* *ever* be upgraded in the stable branch.

>> * Binary packages for a whole X.Y branch would be built on X.0 (e.g. on
>> 7.0 for all 7.x branches).
>>
> Could not this be done already with the current ports?

Yes it could. This is really tangential for the discussion, it concerns
more the "next step" - binary packages and updates.

> I have not used Linux myself in the last 6 years, so I'm not very
> confident with all these 'apt', 'yum' and co, however I have 2 Ubuntu
> installations not far from me. Well, as tools they (apt, ...) may be
> quite good, but I remember the too early update to firefox3
> (which crashed every few minutes and that was an official gnome browser!)
> and the problems with intel video card (hard freeze of the system)
> after upgrade to the new Xorg. So, the tools alone do not solve
> that many problems...

Yes, of course. Most of the problems here are not technical but
organizational. Creating a package manager is relatively easy compared
to the project infrastructure (peopleware) that need to support it.

> Weighting these all, I would say no. There is already enough fun keeping
> ports working on CURRENT. And see below.

Ok.

> Back on topic, would not it be better to provide "official packages for
> upgrades" built from some chosen snapshots of the ports tree?

No, since it doesn't solve the major problem of forced upgrades of
entires subtrees when an ancestor changes (e.g. libgtk, libpng, libjpeg,
qt).

> In some cases (when really needed?) there are already different variants
> of the same port (port / portXY / port-devel).

This makes sense for a very small number of ports. E.g. having PHP 5.2
and 5.3 at the same time in the same ports tree would probably add to
the confusion.

But you *must* upgrade to latest php-5.x port because of security
updates and so you are forced to upgrade php to 5.3 (and everything that
depends on it) even when 5.2 is supported upstream.

_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Ivan Voras on 29 Mar 2010 15:49
Doug Hardie wrote:
> On 29 March 2010, at 08:57, Ivan Voras wrote:
>
>> In some cases the burdens are obvious - the maintainer(s) would need to
>> e.g. maintain three versions of the ports - a random example would be
>> e.g. X.Org 7.0 for 6.x, 7.2 for 7.x and 7.4 for 8.x. Another would be
>> keeping PHP 5.2 for 7.x and 8.x and having 5.3 in the future
>> (CURRENT/9.x) branch.
>
> I am a bit concerned about your concept of maintain, being able to build a port successfully, does not necessarily mean it will work properly. For example, qpopper (which I maintain) has an issue where one feature does not work properly on 64 bit machines where it works fine on 32 bit machines. In addition, there are a number of other machine types that are currently not heavily used but might become so in the future. Thats a lot of different combinations of hardware and OSs to keep running for the maintainers.

It was done (in Linux), hence it can be done. If all else fails and both
the project and the maintainer cannot find suitable build and test
machines, I'd suggest using ONLY_FOR_ARCHS, or doing the whole "stable"
dance only for Tier 1 platforms (enumerated in
http://www.freebsd.org/doc/en/articles/committers-guide/archs.html to be
i386, amd64, pc98). AFAIK from the ports POW, pc98 and i386 are too
close to be considered separately.

Virtualization (VirtualBox) may help maintainers test on the
architecture they don't run natively.

_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

 |  Next  |  Last
Pages: 1 2 3
Prev: Newer autoconf (2.63+)?
Next: Silent distfiles conflict between graphics/xface.el andmail/x-face-e21.