what if a package needs to be "recalled"
 

Just curious, let's say version 15.xxx of a package is released but then
found to be faulty, and upstream isn't releasing a new version soon. Can
the developer somehow recall it? But then peoples' apts won't
automatically catch 14.xxx as the new version if 15.xxx is already
installed. Or he can repackage 14.xxx as "15.xxx.1" but then other
packages depending on > 14 etc. will get the version wrong and the
numbering will be misleading. Yes, users can always install whatever
version they want manually, but I am just curious about damage control
from the point of the developer.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 8739dil62y.fsf@jidanni.org">http://lists.debian.org/8739dil62y.fsf@jidanni.org

what if a package needs to be "recalled"
 

Isn't this one of the reasons for the epoch field?
--
My blog http://etbe.coker.com.au
Sent from an Xperia X10 Android phone


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: a2ef74dc-b5c1-4444-a79f-696ecfff1cb4@email.android.com">http://lists.debian.org/a2ef74dc-b5c1-4444-a79f-696ecfff1cb4@email.android.com

what if a package needs to be "recalled"
 

Just curious, let's say version 15.xxx of a package is released but then
found to be faulty, and upstream isn't releasing a new version soon.

OK...... faulty is a rather vauge term


Can the developer somehow recall it?

Not really, it's probablly theoretically possible to remove a package from debian and then
reupload a lower version but it would require the intervention of the ftpmasters and
it wouldn't achive much because as you say people would have already upgraded.


Or he can repackage 14.xxx as "15.xxx.1" but then other
packages depending on > 14 etc. will get the version wrong and the
numbering will be misleading.

It's possible to use a version number like 15.xxx+really14.xxx but it's ugly to say the least

It's also possible to use an epoch e.g. 1:14.xxx, downside of that approch is that the
package has to carry the epoch forever.

Afaict it's pretty rare that a package that is so badly broken that reversion is considred
the only reasonable course of action makes it into debian.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EC994C2.6070906@postgrad.manchester.ac.uk">http://lists.debian.org/4EC994C2.6070906@postgrad.manchester.ac.uk

what if a package needs to be "recalled"
 

Russell Coker wrote:

> Isn't this one of the reasons for the epoch field?

No. If chromium 14.0.835.202~r103287-1 actually worked[1], the
thing to do would be to upload a package with version number
15.0.874.106~r107270+really14.0.835.202~r103287-1. That way,
the blip in version numbering can be only temporary.

[1] Alas, it doesn't work: http://bugs.debian.org/649378


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111121000958.GA11473@elie.hsd1.il.comcast.net">h ttp://lists.debian.org/20111121000958.GA11473@elie.hsd1.il.comcast.net

what if a package needs to be "recalled"
 

On Sun, Nov 20, 2011 at 7:01 PM, peter green wrote:
>> Or he can repackage 14.xxx as "15.xxx.1" but then other
>> packages depending on > 14 etc. will get the version wrong and the
>> numbering will be misleading.
>
> It's possible to use a version number like 15.xxx+really14.xxx but it's ugly
> to say the least

If this thread is specifically related to the broken sandbox in
chromium right now, then you can use "chromium --no-sandbox" until we
find an appropriate fix the bug (or help us do that). No need to come
up with crazy versioning solutions.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CANTw=MMcreu6rLWnA8dvyhNTuSFHt7der=YPsGg6Nam+SZbQg g@mail.gmail.com">http://lists.debian.org/CANTw=MMcreu6rLWnA8dvyhNTuSFHt7der=YPsGg6Nam+SZbQg g@mail.gmail.com

what if a package needs to be "recalled"
 

On dim., 2011-11-20 at 20:56 -0500, Michael Gilbert wrote:
> If this thread is specifically related to the broken sandbox in
> chromium right now, then you can use "chromium --no-sandbox" until we
> find an appropriate fix the bug (or help us do that). No need to come
> up with crazy versioning solutions.

I'm not sure telling people to use --no-sandbox without telling them
what they lose is a good idea. Sandboxing is here for a reason.

Regards,
--
Yves-Alexis

what if a package needs to be "recalled"
 

>>>>> "YP" == Yves-Alexis Perez <corsac@debian.org> writes:

YP> I'm not sure telling people to use --no-sandbox without telling them
YP> what they lose is a good idea. Sandboxing is here for a reason.

Wish it was documented. Say on the man page.

Of course if they don't use it, they won't be able to browse anything.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87aa7mqsyi.fsf@jidanni.org">http://lists.debian.org/87aa7mqsyi.fsf@jidanni.org

what if a package needs to be "recalled"
 

On Wed, Nov 23, 2011 at 7:12 PM, wrote:
>>>>>> "YP" == Yves-Alexis Perez writes:
>
> YP> I'm not sure telling people to use --no-sandbox without telling them
> YP> what they lose is a good idea. Sandboxing is here for a reason.

I find the "no-sandbox" label sufficiently descriptive, but for
completeness sake, this option will (as it sounds) disable chromium's
process isolating "sandbox" feature. This means that the security
hardening feature, which normally makes it very hard for data to leak
between chromium processes (i.e. tabs), will be off.

It is of course not a permanent solution.

> Wish it was documented. Say on the man page.

You're certainly free to create a patch with that documented ;) The
problem is that chromium commands change rapidly. It may be better
just to link to this page, which gets updated fairly regularly:
http://peter.sh/experiments/chromium-command-line-switches/

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CANTw=MP53P7uuVFYiMGZcjyWuYCoM=3gncb3VLLiBhF5KtrxQ Q@mail.gmail.com">http://lists.debian.org/CANTw=MP53P7uuVFYiMGZcjyWuYCoM=3gncb3VLLiBhF5KtrxQ Q@mail.gmail.com

what if a package needs to be "recalled"
 

On Wed, Nov 23, 2011 at 7:43 PM, Michael Gilbert wrote:
> On Wed, Nov 23, 2011 at 7:12 PM, *wrote:
>>>>>>> "YP" == Yves-Alexis Perez writes:
>>
>> YP> I'm not sure telling people to use --no-sandbox without telling them
>> YP> what they lose is a good idea. Sandboxing is here for a reason.
>
> I find the "no-sandbox" label sufficiently descriptive, but for
> completeness sake, this option will (as it sounds) disable chromium's
> process isolating "sandbox" feature. *This means that the security
> hardening feature, which normally makes it very hard for data to leak
> between chromium processes (i.e. tabs), will be off.

And of course makes it hard (hopefully) for attackers to break out of
that sandbox to get access (read/write) to anything else in memory.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CANTw=MMegNX3J70FfY7r6Who7Nbrc=ZwD=yGd79bSTPGOktOw g@mail.gmail.com">http://lists.debian.org/CANTw=MMegNX3J70FfY7r6Who7Nbrc=ZwD=yGd79bSTPGOktOw g@mail.gmail.com