FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 11-10-2008, 06:18 PM
Les Mikesell
 
Default Proposal: Rolling Release

Jesse Keating wrote:

On Mon, 2008-11-10 at 12:52 -0600, Callum Lerwick wrote:

Debian can do this. The only reason we can not is because we refuse
to.


And so far we refuse to be cause we allow free-form scriptlets in rpms.

It would be interesting to see how one would upgrade say mysql major
version and then roll it back all via packaging. Something that
requires changing the on disk format of your databases and such.


And the answer to that is that sometimes interactive choices need to be
made during installation/upgrade/downgrade operations. Or they can't be
done with a package at all.


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-10-2008, 06:31 PM
Rahul Sundaram
 
Default Proposal: Rolling Release

Les Mikesell wrote:

Jesse Keating wrote:

On Mon, 2008-11-10 at 12:52 -0600, Callum Lerwick wrote:

Debian can do this. The only reason we can not is because we refuse
to.


And so far we refuse to be cause we allow free-form scriptlets in rpms.

It would be interesting to see how one would upgrade say mysql major
version and then roll it back all via packaging. Something that
requires changing the on disk format of your databases and such.


And the answer to that is that sometimes interactive choices need to be
made during installation/upgrade/downgrade operations. Or they can't be
done with a package at all.


They can't be done then since RPM doesn't support interactive
installations. It is designed to be completely automatic. If you have to
ask questions in the middle of a transaction, you lose anyway.


Rahu;

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-10-2008, 06:34 PM
 
Default Proposal: Rolling Release

On Mon, 10 Nov 2008, Callum Lerwick wrote:


On Mon, 2008-11-10 at 23:35 +0530, Rahul Sundaram wrote:

The real missing piece is 'undo' when you find out that a change in the
new version breaks something that you need. Does anyone know if that
actually works on systems using conary (i.e. can you back up a major
revision)?


Not feasible for RPM due to pre/post scripts. The rudimentary roll back
support in RPM has actually been removed in 4.6. It probably needs the
underlying filesytem to support snapshots. Something like btrfs needs to
be in place first.


We need rollback if we ever want to be serious about end-user testing.

With non-critical (as in, not needed for yum to run...) packages an "rpm
-e somepackage --nodeps" "yum install somepackage" offers something of a
rollback...

Filesystem rollback may work for full-distribution upgrade rollback, but
won't work so well for per-package rollback. A user should be able to
cherry pick updates to try from "updates-testing", and easily roll back
individual packages, or their entire system to "updates" or even the
"fedora" repo should something go wrong.

Debian can do this. The only reason we can not is because we refuse to.


The above use-case (perfectly valid use-case, mind you) is a very very
limited special case of rollback called "software downgrade". And that rpm
can handle just as well or badly as dpkg - it all depends on the software
in question, what its scriptlets do or don't do etc.


The question is, how would the package management toolchain be able to
differentiate "oops db4-4.7.21-4 from updates-testing crashes with a NULL
pointer thinko, gimme back db4-4.7.21-3 from stable repo" from "db4 update
from 4.5 to 4.6 broke things and testing it converted my db to 4.6 format
so downgrading back to 4.5 wouldn't do any good" and act intelligently in
both cases? One heuristic would be allowing downgrade between different
releases of the same version more freely but scriptlets can do damage even
in release bumps.. thats no solution either.


- Panu -

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-10-2008, 06:50 PM
Les Mikesell
 
Default Proposal: Rolling Release

Rahul Sundaram wrote:



On Mon, 2008-11-10 at 12:52 -0600, Callum Lerwick wrote:

Debian can do this. The only reason we can not is because we refuse
to.


And so far we refuse to be cause we allow free-form scriptlets in rpms.

It would be interesting to see how one would upgrade say mysql major
version and then roll it back all via packaging. Something that
requires changing the on disk format of your databases and such.


And the answer to that is that sometimes interactive choices need to
be made during installation/upgrade/downgrade operations. Or they
can't be done with a package at all.


They can't be done then since RPM doesn't support interactive
installations. It is designed to be completely automatic. If you have to
ask questions in the middle of a transaction, you lose anyway.


So the RPM design forces you to not use it at all. Great. But, that
brings back the concept of migration. Is there any interest in that, so
your upgrade becomes a non-destructive copy that you can test before the
old copy is gone? Disk space is cheap these days.


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-10-2008, 07:02 PM
Rahul Sundaram
 
Default Proposal: Rolling Release

Les Mikesell wrote:

So the RPM design forces you to not use it at all. Great.


Deb or other package management systems are no different here. They are
all designed to be non-interactive. Debian used to dump questions on a
terminal for some packages but that is not recommended anymore for
obvious reasons and everybody is advised to used to use debconf. There
is only limited magic you can do to workaround incompatibilities of
certain kinds. Postgres frequently requires a dump and restore.


But, that
brings back the concept of migration. Is there any interest in that, so
your upgrade becomes a non-destructive copy that you can test before the
old copy is gone? Disk space is cheap these days.


You have to explain how that will work for a complex dependency set.
What about say glibc breakage? You are going to need filesystem
snapshots I suspect.


Btw, disk space is not always cheap. Think: thin clients, embedded
systems, netbooks like OLPC or eeepc etc.


Rahul

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-10-2008, 08:01 PM
Les Mikesell
 
Default Proposal: Rolling Release

Rahul Sundaram wrote:


So the RPM design forces you to not use it at all. Great.


Deb or other package management systems are no different here. They are
all designed to be non-interactive. Debian used to dump questions on a
terminal for some packages but that is not recommended anymore for
obvious reasons and everybody is advised to used to use debconf. There
is only limited magic you can do to workaround incompatibilities of
certain kinds. Postgres frequently requires a dump and restore.


And you may need both old and new versions present while you perform the
operations an upgrade requires. So generic package-magic would involve
being able to install the new version without removing the old so you
have a chance to do the interactive parts before it is too late. That
would be a nice feature to have in general but pretty far from existing
practice.



But, that
brings back the concept of migration. Is there any interest in that,
so your upgrade becomes a non-destructive copy that you can test
before the old copy is gone? Disk space is cheap these days.


You have to explain how that will work for a complex dependency set.
What about say glibc breakage? You are going to need filesystem
snapshots I suspect.


I'd like it to not touch the existing system at all. One approach
would be to migrate to a different machine, which I consider a badly
needed feature on its own. Macs have done this for years, using
firewire target mode on the old system to access it as a disk drive and
providing automated copy plus update of the existing users,
applications, and data. Any technique that permits a backup/restore of
the old system followed by an upgrade that would also do the fixup for
potentially different hardware would work, though. Building a
virtualbox/vmware (etc.) clone should be a transparent variation of
this, but you need the 'migrate to hardware' tool that doesn't exist.


Another would be to have pre-allocated a spare partition - or add a new
one, perhaps via USB where you copy the old system, then upgrade, making
a dual-boot setup so you can go back to an untouched existing system if
necessary. In the USB case, you would need a subsequent migration step
to move the partition over the old system after you were convinced it
was safe. I've done alternate-partition installs manually in the past
but it takes some tweaking, and if you maintain the existing /home,
there is no way to know which files you need to save/restore between
versions so that should be automated too.


Btw, disk space is not always cheap. Think: thin clients, embedded
systems, netbooks like OLPC or eeepc etc.


Think USB external, flash or laptop form. They are great things to have
around for other purposes too.


--
Les Mikesell
lesmikesell@gmail.com



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-10-2008, 09:30 PM
Rahul Sundaram
 
Default Proposal: Rolling Release

Les Mikesell wrote:

And you may need both old and new versions present while you perform the
operations an upgrade requires. So generic package-magic would involve
being able to install the new version without removing the old so you
have a chance to do the interactive parts before it is too late.


Again, this is something upstream project should do. GTK and gstreamer
for example does make this easy.


http://www106.pair.com/rhp/parallel.html

Working around this at the packaging level is always going to require
elaborate hacks. OpenSUSE did this for shipping KDE 3 and KDE 4 in
parallel but other distributions refused.


Think USB external, flash or laptop form. They are great things to have
around for other purposes too.


External USB's are not a answer in embedded systems. You cannot rely on
external disk storage for base os functionality.


Rahul

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-10-2008, 10:13 PM
Les Mikesell
 
Default Proposal: Rolling Release

Rahul Sundaram wrote:


And you may need both old and new versions present while you perform
the operations an upgrade requires. So generic package-magic would
involve being able to install the new version without removing the old
so you have a chance to do the interactive parts before it is too late.


Again, this is something upstream project should do. GTK and gstreamer
for example does make this easy.


http://www106.pair.com/rhp/parallel.html

Working around this at the packaging level is always going to require
elaborate hacks. OpenSUSE did this for shipping KDE 3 and KDE 4 in
parallel but other distributions refused.


I'm not sure I understand the logic of making upstream deal with the
problem that RPM's design introduces. There's rarely an issue if you
want to do parallel version installs out of an upstream source - and I'd
guess the developers _always_ do that for anything they rely on.


Think USB external, flash or laptop form. They are great things to
have around for other purposes too.


External USB's are not a answer in embedded systems. You cannot rely on
external disk storage for base os functionality.


OK, so there are tradeoffs. If you are building embedded systems you
probably need a spare one to test on. You really only need the backout
capability until someone has thoroughly tested the replacement in the
environment where it needs to run. Or add a micro-sd slot so you can
throw in an extra 16 gigs in an itty-bitty package when you need it -
even my phone can do that...


As a minimal step you could add the capability of clonezilla to the
install - that is, offer to save a compressed image backup somewhere
before starting in a form that can be restored without a lot of work.
That's not quite as nice as keeping old/new filesytems online so work in
progress could be accessed/recovered from either version, but better
than nothing.


--
Les Mikesell
lesmikesell@gmail.com


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-11-2008, 12:13 AM
Bojan Smojver
 
Default Proposal: Rolling Release

Eric Springer <erikina <at> gmail.com> writes:

> So what I propose is that Fedora goes to a rolling release cycle.

Fedora is these days more than a collection of applications. Each release is
supposed to bring better integration of everything shipped within the release.
So, when you say:

> New features/software/functionality would be easily tested by the masses
without needing to upgrade the entire distribution.

I'm not so sure about the "easily" bit.

Let's say disconnected non-local authentication got addressed by various
components. How are you going to test this without pulling in the whole new
distro if something in say glibc got changed to accommodate it? Very hard to do
and not worth the trouble of risking massive breakage this can cause.

It's a pipe dream, IMHO.

--
Bojan



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-11-2008, 02:31 AM
"Arthur Pemberton"
 
Default Proposal: Rolling Release

On Mon, Nov 10, 2008 at 7:42 AM, Eric Springer <erikina@gmail.com> wrote:
> Fedora has always lead the progress of FOSS by closely following
> upstream and making non-trivial contributions. I see this is a great
> strength, and like many other people it's my primary reason for using
> it. But it's not without trade-offs, such as giving Fedora a
> perception of being 'beta' software and balancing new software without
> burning the large user base is not easy either.

Yes. That is a fact. There is almost no good way to tell people who
don't like this "get used to it". Someone has to do this. Someone has
to be the "custodian" and it seems like we (Fedora) are it. And I feel
that we should be proud of our role on the frontlines.

I think that as long as we do not burn these users away from Linux as
a whole, this is okay.

> This hit home today, after being impressed with the work you guys have
> done with plymouth, I did a quick Google search[1] to find out a
> little more. The first result is a "Ubuntu brainstorm" page[2] about
> implementing it in their own distribution and the second comment is "I
> support the idea but I do think that it should only be considered
> after Fedora has done all the dirty work of getting it to work".

I feel like this is something for Fedora to be proud of. It is a
community, and different parts have their niches, this seems to be
Fedora's own, and we should be proud of it.

> This
> is no way intended as a criticism of a Ubuntu, but it's a realization
> that distributions like Ubuntu are able to offer a better user
> experience by using stable software on a longer support cycle.

And this is good thing. Ubuntu has not shown themselves capable of
doing anything else but this, so let the, have that. If anything, we
need an easier migration path between Fedora and Ubuntu.

> So what I propose ...

I read through everything, but just wanted to shorten the email a bit..
This all sounds good, but it seems entirely like a good idea, which
needs a lot of resources and additional man power to do. Without the
added man power, we would likely be taking away from what makes Fedora
Fedora as is today.

We are Fedora, do we need to be Ubuntu as well?

--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 09:43 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org