Mailing List Archive

On Jun 12, 2007, at 1:27 PM, Luca Barbato wrote:

> any ebuild from day 0 till now lives in the cvs, you can fetch it from
> the cvs attic anytime, I'm afraid this information isn't exactly well
> known =/

I am aware of it, but this means much more "frickle"-time (forget
frickle if you don't know it :).
--
gentoo-dev@gentoo.org mailing list

On Jun 12, 2007, at 1:29 PM, Christoph Mende wrote:

> It's not, CVS keeps every ebuild around, just go to sources.gentoo.org
> and hit "Show X dead files" in the dir of the ebuild you want ;)

so you misunderstood comfortably :)
--
gentoo-dev@gentoo.org mailing list

On Jun 12, 2007, at 1:21 PM, Petteri Räty wrote:

> Nope and they should usually be kept but we can't make a hard rule
> because there are cases where the old ebuilds don't work any more. If
> you find that a broken version slipped the cracks of the arch teams
> and
> made it to stable with the old version removed, file a bug to
> bugs.gentoo.org and hopefully the maintainer learns from his/her
> mistake
> of removing it too soon. If the maintainer keeps on doing the same
> thing, then you can try to escalate things to qa/devrel. If you are
> using ~arch, then encountering some broken stuff is fully expected,
> just
> file a bug and the maintainer is expected to react in a timely manner.

I agree, if an ebuild is broken then it should be removed since it
doesn't work at all. But rather than exchanging the broken ebuild
with a version bump it is sometimes more advisable to repair the
broken ebuild and increase the integer of -rx instead of replacing
the broken ebuild with a masked one. Very often bugs are filed after
a package has been unmasked and so it is better to have a working
older ebuild.

Of course, this is just a case scenario which may happen. To prevent
such rare cases is in mind of every user. Well, I still think, leave
it up to the users and give them time to choose between ebuilds and
move them to overlay, instead of forcing them to query the source for
dead packages.--
gentoo-dev@gentoo.org mailing list

On Jun 12, 2007, at 1:25 PM, Christian Faulhammer wrote:

> That is not by purpose. Most people clean-up a package when
> stabilisation round has been done. So I must say clarify my first
> statement: I think it is a good idea to have old stable versions in
> the
> tree, but that should be the choice of the dev in the end without
> strict rules.

So what do we do with `the may be 5%` *) of packages this behaviour
is not working?

*) imaginary number
--
gentoo-dev@gentoo.org mailing list

Btw, both of your issues could probably be solved by bug 126059 without
adding new rules or new work for ebuild devs.

--
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

On Jun 12, 2007, at 2:55 PM, Marius Mauch wrote:

> Btw, both of your issues could probably be solved by bug 126059
> without
> adding new rules or new work for ebuild devs.

Thanks a lot for this, I totally agree.
--
gentoo-dev@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

cilly wrote:
> On Jun 12, 2007, at 12:46 PM, Fernando J. Pereda wrote:
>
>> Known to be buggy versions.
>
> Of course, there are bugs in every version. Sometimes a user must be
> able to choose which bug is more problematic, i.e. the bug in the newer
> ebuild which makes the package unusable for them or the older bug which
> has a security issue the users are aware of but not present, i.e.
> prevented by firewall. A timeline of two weeks would allow the user to
> easily downgrade and if necessary put the ebuild in overlay.

Hello,

We (developers) won't immediately remove old packages versions if there
is no a good reason for it, at least in my case.

One of the main motivation for fast removal are security concerns, they
sometimes happen and they don't even get into our bugzilla database ,
but the maintainer of the package is aware of it from upstream reports,
so these might be "unknown" problems for our users.

Best recommendation is that you trust the package maintainer and report
bugs in the new packages if you find them.

Regards,

- --

Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)

iD8DBQFGbsQ8aTNpke9pJcURAugPAJ9MuOmIFMzNNAx7DqKCm/ZuxLj5mACfcOf/
W3oxNo4aXWZLGlT9D5HblQ4=
=GLS5
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

cilly <cilly@cilly.mine.nu> posted
4FA373CA-773E-4390-BD91-70F87510D6D9@cilly.mine.nu, excerpted below, on
Tue, 12 Jun 2007 12:59:42 +0200:

> On Jun 12, 2007, at 12:53 PM, cilly wrote:
>
>> Of course, there are bugs in every version. Sometimes a user must be
>> able to choose which bug is more problematic, i.e. the bug in the newer
>> ebuild which makes the package unusable for them or the older bug which
>> has a security issue the users are aware of but not present, i.e.
>> prevented by firewall. A timeline of two weeks would allow the user to
>> easily downgrade and if necessary put the ebuild in overlay.
>
> Additional:
>
> Sometimes the chance for the users to place the ebuild comfortably into
> overlay is simply taken, since the ebuild has been removed and doesn't
> exist after a sync anymore.

Keeping this short since the user list would be more appropriate for this
sort of thing, but I've not seen it mentioned in the thread yet.

That's one of several reasons I find FEATURES=buildpkg so useful. It is
IMO the most under-publicized great feature of portage. =8^) Really.
Read about it, then try it for awhile, and if you don't agree, look in
the forums or ask on users for some hints on the troubleshooting and
rescue methods it makes possible or much easier. (Specific hint for this
thread, the ebuild is tacked onto the end of the tar.bz2-ed compressed
package. That's been useful to me a couple times.)

If people only knew some of the great features portage already has, the
wouldn't keep asking for them. =8^) Features=buildpkg is one such
feature.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

--
gentoo-dev@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Am 12.06.2007 um 13:29 schrieb Christoph Mende:

> On Tue, 12 Jun 2007 12:59:42 +0200
> cilly <cilly@cilly.mine.nu> wrote:
>
>> On Jun 12, 2007, at 12:53 PM, cilly wrote:
>> Additional:
>>
>> Sometimes the chance for the users to place the ebuild comfortably
>> into overlay is simply taken, since the ebuild has been removed and
>> doesn't exist after a sync anymore.
> It's not, CVS keeps every ebuild around, just go to sources.gentoo.org
> and hit "Show X dead files" in the dir of the ebuild you want ;)

The problem is rather that the patches are gone from the distfiles
mirror after two weeks. The sources often stay upstream, but could
also be gone.

Is there an archive for these files I missed?

Robert

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGcACzyZx3L/ph1soRAutQAKCMQ2f6nCzoXgATbIPTO6sbTv32ugCeP+JP
tqC13Sfmy1t30jU6aCWgZug=
=A832
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

Hi,

my opinion is to make the sync machanism more intelligent in this way.
I don't want to have a tree with 2 stable versions or old versions of
ebuilds.
My idea is to let the actual(old) installed ebuild version untouched so you
are able to downgrade after an update, and you are although able to
downgrade to you old stabe version if it is older than just the last version
of the ebuild.

In this way you don't have the problem in the official tree because
everybody is able to downgrade to his old version no matter how old.

so but just an idea

banym

On Wed, Jun 13, 2007 at 04:35:31PM +0200, Robert Buchholz wrote:
> The problem is rather that the patches are gone from the distfiles
> mirror after two weeks. The sources often stay upstream, but could
> also be gone.
>
> Is there an archive for these files I missed?

That archive ('purgatory' being the name used for it) isn't publically
accessible; had suggested it in the past, but infra folks didn't
think it would be needed.

Few issues if it were opened up;

1) it's not a true vcs, just a directory. Meaning

1.a) it's collapsing down the trees history of distfile names; if
ebuild x refs 'patch', gets removed, 'patch' goes into purgatory. If
ebuild y refs 'patch', which is a different file, then gets removed,
ebuild ys' version of 'patch' is whats is now in purgatory (last used
basically).

1.b) skimped a bit in the description above; 'patch' gets removed from
purgatory when ebuild 'y' is added to the tree- the chksums will
differ, thus it throws out the copy that no longer is relevant to it's
job (maintaining the mirror image).


2) if implemented, likely to be a single box- meaning stuff shouldn't
rely on it as an upstream URI, they should mirror it themselves.

3) mirror maintenance, if an ebuild is added to the tree that uses
that specific distfile name, as hinted at in 1.b, the file is removed
from purgatory- this *includes* if the chksums match. Basically, if
the file is needed on the mirror image, it copies it over and wipes
the purgatory copy of it (intention is to keep space usage down).
This obviously would break any ebuilds daftly ignoring #2, and using
the purgatory host as an upstream URI.


Personally, I think at least for devs, having access to purgatory
would be a good thing. Folks seem to have learned over the last few
years, but dealt with a lot of requests where a dev screwed up and
needed to pull a file out of purgatory. Perhaps they've gotten wiser
since, dunno. Either way, if trying to pull a file out of
purgatory, bug your friendly infra monkey, or zmedico if you need a
specific file out- they ought to have access.

For effectively random anonymous, http/ftp, not sure about
that. Think some form of access is needed, don't think it should
really be usable as an upstream host.

~harring