[gentoo-project] Automation: Making package.mask better

[gentoo-project] Automation: Making package.mask better

[Alec Warner]

My goal here is to improve the speed at which developers work and
making it easier to do things, hence the 'automation' series of mails
(of which this is the first of hopefully many).

Todays subject is package.mask.

Package.mask is a file read by both the package mangler and humans to
determine if a given CP(V) is masked or not, and also to try and
determine who did the masking, when, and why.

None of these fields are required, but are usually present by convention.

The intent here is to formalize the format of package.mask by
introducing what i'll term 'fields'.  Fields may be required, or
optional.  Fields may contain data, typically in the form of ASCII
text.  The intent of adding fields is to ensure that all masks contain
mandatory information.

Right now the present convention would have the following fields.

Author:  Who commited the mask.
Date: When was it masked.
Reason: 1 or more lines describing a rationale for the masking.
Packages: one or more lines of text, 1 atom per line, describing
packages affected by this mask entry.

I wish to add a few more fields:

Effective-Date: Date the mask goes into effect.  This means you can
mask stuff in the future.
Expiration-Date: Date the mask ends.  This means you can have masks
that expire after a given time.

If Expiration-Date was mandatory, we could essentially have a system
that cleans out mask files by removing expired masks.

I currently am seeking feedback about the idea of adding more fields
to package.mask and the examples provided in this e-mail in no way
represent any given implementation (for which there is currently
none).  Certainly adding more fields places a burden on the package
manager to exclude entries that are not within the Effectived ->
Expiration date range.  And of course, backwards compatability is
always a bitch.

Another thing I wish to address is the addition of entries in
package.mask at the top of the file.  I think this restriction just
makes automation more difficult.  I can't just append new entries to
the end of the file, I have to read in the file and figure out by some
hardcoded comment strings where the actaul masks begin, and then
insert text right below the examples.  This is horrible.  Can we nuke
that convention, why are new entries at the top?

-Alec
-- 
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[David Shakaryan]

Alec Warner wrote:
> Effective-Date: Date the mask goes into effect.  This means you can
> mask stuff in the future.
> Expiration-Date: Date the mask ends.  This means you can have masks
> that expire after a given time.

While I do not see a problem with Effective-Date, I do not think 
Expiration-Date is too good of an idea as it would be quite easy for it 
to backfire and have a negative effect.

For example, someone might decide to remove a package from the tree and 
mask it with an expiration date, but forget to remove the package before 
the mask expires. Small, careless mistakes like these may lead to much 
larger problems.

If this is at all implemented, it must be made *clear* that this should 
only be used for certain scenarios where it can not become a problem, 
such as when masking a package with an expiration date of when the 
package is scheduled to hit the official mirrors. Even then, it can 
become somewhat of a problem if there is a gap between when the packages 
should hit the mirrors and when they actually do, as it would result in 
404 errors.

While automation of this may lead to things being *slightly* simpler and 
quicker, it may also lead to problems in the future. It would be much 
more fool-proof to manually remove masks than to have a feature such as 
this.

-- 
David Shakaryan
-- 
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[René 'Necoro' Neumann]

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

Hmm ... automation:

Without saying something on whether it would be useful or not, I think
that we should change the format to sth which can be processed easily by
programs (XML for instance). To ensure human readibility, one could keep
the text file and have the xml one addtionally.

Then the whole process of adding fields is rather simple :)

Regards,
Necoro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGoxxj4UOg/zhYFuARAp/iAJ4/lRexyZmXZgAHMtmIMTAZIoq2/ACdGslm
SNrM3Ae5cb72soY6/Xrm5Lk=
=mOXZ
-----END PGP SIGNATURE-----
-- 
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[Robert Buchholz]

On Sunday, 22. July 2007 08:39, Alec Warner wrote:
> Author:  Who commited the mask.
> Date: When was it masked.
> Reason: 1 or more lines describing a rationale for the masking.
> Packages: one or more lines of text, 1 atom per line, describing
> packages affected by this mask entry.
>
> I wish to add a few more fields:
>
> Effective-Date: Date the mask goes into effect.  This means you can
> mask stuff in the future.
> Expiration-Date: Date the mask ends.  This means you can have masks
> that expire after a given time.
>
> If Expiration-Date was mandatory, we could essentially have a system
> that cleans out mask files by removing expired masks.

I like the idea, here's my comments:

1. For backwards compatibility, we could just put all fields into 
comments (as it is done now) except for the masked atoms, like this:

# Author: Alec Warner <antarus@gentoo.org>
# Date: 05 Feb 2007
# Reason: Masked to security problems, use 1.23-r1 until I fix it
# ...
>=app-admin/ulogd-1.24

The dates usage and parsing could than be added later, while using the 
format and automation itself today.

2. The pro's of using it today would be to mark Last-Rites (just what 
makes me think that discussion led you to the idea?).
I can think of several ways to do this. We could have an 
optional "Removal-Date" field and if it is set, the package is last 
rited

3.  We could also introduce some kind of "Keywords" as in Bugzilla to 
mark certain situations, as UNUSABLE, SECURITY, LASTRITED. Do we need 
that?

4. How do we handle updates to the an entry, esp. the Date and Author 
section?


> Another thing I wish to address is the addition of entries in
> package.mask at the top of the file.  I think this restriction just
> makes automation more difficult.  I can't just append new entries to
> the end of the file, I have to read in the file and figure out by
> some hardcoded comment strings where the actaul masks begin, and then
> insert text right below the examples.  This is horrible.  Can we nuke
> that convention, why are new entries at the top?

Drop the convention then... or we could add a marker line at the top
"## New entries start here" - Would that make it easier?

Robert
-- 
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[Roy Bamford]

On 2007.07.22 07:39, Alec Warner wrote:
> My goal here is to improve the speed at which developers work and
> making it easier to do things, hence the 'automation' series of mails
> (of which this is the first of hopefully many).
> 
> Todays subject is package.mask.
> 
> Package.mask is a file read by both the package mangler and humans to
> determine if a given CP(V) is masked or not, and also to try and
> determine who did the masking, when, and why.

[snip]

> 
> -Alec
> -- 
> gentoo-project@gentoo.org mailing list
> 
> 

Alec,

Standardisation is a good thing, it certainly aids automation, so I 
don't have an issue with defining any fields you like. The automatic 
use of dates I can see a problem with.

Packages are masked for three reasons
1. At the beginning of life. They are not yet ready for everyday use.
2. They were released and now there is a major bug.
3. At end of life, before they are removed.

All of these scenarios need something else to happen manually before 
the future date is reached. Some examples may be better.

1. Lets say I'm waiting for KDE 5 and I have ebuilds in my tree masked 
with future dates set. I'm so keen to get it, the date arrives and I do 
emerge kde-meta
Hopefully, the ebuilds I have are still not keyworded, so nothing nasty 
happens. I do emerge --sync and get updated ebuilds and an updated 
package.mask with new (later) future dates. No harm done.
What if the packages were already keyworded ?

2 and 3 are pretty much the same.
They depend on a fix or package removal happening before the future 
date is reached. We all know that fixes take as long as they take.
For removals, the removal process would need to be automated using the 
same or an earlier date.

I do see one way round these complications though. 
Force an emerge --sync 
of package.mask and the affected ebuilds before implementing any date 
released features. After all, future dates represent plans, its as well 
to check the plan worked before acting on it.

Regards,

Roy Bamford
(NeddySeagoon) 

--
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[Marijn Schouten (hkBst)]

Alec Warner wrote:
> If Expiration-Date was mandatory, we could essentially have a system
> that cleans out mask files by removing expired masks.

Can't we already (automatically) remove masks for which the relevant ebuilds 
have been removed? Is there another situation for which you think this is useful?

Marijn
-- 
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[Marijn Schouten (hkBst)]

� wrote:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 >
 > Hmm ... automation:
 >
 > Without saying something on whether it would be useful or not, I think
 > that we should change the format to sth which can be processed easily by
 > programs (XML for instance).

Yes, we could use s-expressions. They are as powerful as XML, but not so 
insanely verbose.

 > To ensure human readibility, one could keep
 > the text file and have the xml one addtionally.

I don't think anybody wants to duplicate work like that. Anyway, s-expressions 
are easy to read for humans as well as computers.

Marijn
-- 
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[James Cloos]

>>>>> "Alec" == Alec Warner <antarus@gentoo.org> writes:

Alec> Todays subject is package.mask.

Just a side note, but don't forget about users and their
/etc/portage/package.(un)?mask files.

Any automation which would be useful for devs editing mask
files in portage and overlays is also of use for users.

(And -- as already mentioned -- if the syntax is to change,
 please go with sexps rather than xml.)

(pretty-please)

;-)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6
-- 
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[Vlastimil Babka]

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

Roy Bamford wrote:
> 1. Lets say I'm waiting for KDE 5 and I have ebuilds in my tree masked 
> with future dates set. I'm so keen to get it, the date arrives and I do 
> emerge kde-meta
> Hopefully, the ebuilds I have are still not keyworded, so nothing nasty 
> happens. I do emerge --sync and get updated ebuilds and an updated 
> package.mask with new (later) future dates. No harm done.
> What if the packages were already keyworded ?
> 
> 2 and 3 are pretty much the same.
> They depend on a fix or package removal happening before the future 
> date is reached. We all know that fixes take as long as they take.
> For removals, the removal process would need to be automated using the 
> same or an earlier date.
> 
> I do see one way round these complications though. 
> Force an emerge --sync 
> of package.mask and the affected ebuilds before implementing any date 
> released features. After all, future dates represent plans, its as well 
> to check the plan worked before acting on it.

Too clumsy, just use the date of the local tree snapshot (gets rsynced
in some file IIRC, or extract it from CVS for CVS checkouts) instead of
local date, to compare with dates in p.mask.

Anyway I also can't think of useful and safe uses for the expiration
date. But I agree with the rest of the proposal :)

- --
Vlastimil Babka (Caster)
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGo4DjtbrAj05h3oQRArYJAJ430WTpT+nNPZC6+HqB2A3o/9Gk/wCgkPhk
Fj0O088xeYXk6U9yfqhsTJs=
=cJnK
-----END PGP SIGNATURE-----
-- 
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[Robert Buchholz]

On Sunday, 22. July 2007 14:18, Marijn Schouten (hkBst) wrote:
> � wrote:
>  > -----BEGIN PGP SIGNED MESSAGE-----
>  > Hash: SHA1
>  >
>  > Hmm ... automation:
>  >
>  > Without saying something on whether it would be useful or not, I
>  > think that we should change the format to sth which can be
>  > processed easily by programs (XML for instance).
>
> Yes, we could use s-expressions. They are as powerful as XML, but not
> so insanely verbose.
>
>  > To ensure human readibility, one could keep
>  > the text file and have the xml one addtionally.
>
> I don't think anybody wants to duplicate work like that. Anyway,
> s-expressions are easy to read for humans as well as computers.

Why does the (text based) format of the file need to change at all?
Can't the metadata just be optional comments that are interpreted if 
present. This would keep upwards compatibility for older pm versions as 
well as easy local (un-)maskings for users, as already mentioned by 
James Cloos.

-R.
--
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[René 'Necoro' Neumann]

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

Alec Warner schrieb:
> On 7/22/07, Robert Buchholz <rbu@gentoo.org> wrote:
>> On Sunday, 22. July 2007 14:18, Marijn Schouten (hkBst) wrote:
>> > � wrote:
>> >  > -----BEGIN PGP SIGNED MESSAGE-----
>> >  > Hash: SHA1
>> >  >
>> >  > Hmm ... automation:
>> >  >
>> >  > Without saying something on whether it would be useful or not, I
>> >  > think that we should change the format to sth which can be
>> >  > processed easily by programs (XML for instance).
>> >
>> > Yes, we could use s-expressions. They are as powerful as XML, but not
>> > so insanely verbose.
>> >
>> >  > To ensure human readibility, one could keep
>> >  > the text file and have the xml one addtionally.
>> >
>> > I don't think anybody wants to duplicate work like that. Anyway,
>> > s-expressions are easy to read for humans as well as computers.
>>
>> Why does the (text based) format of the file need to change at all?
>> Can't the metadata just be optional comments that are interpreted if
>> present. This would keep upwards compatibility for older pm versions as
>> well as easy local (un-)maskings for users, as already mentioned by
>> James Cloos.
>>
>> -R.
> 
> I never requested to change the format, I merely wanted to add data
> and make additions go at the bottom.  Other crazy people brought up
> the other formats.
> 
> -Alec

It has been a proposal only ... :) As I thought that automatic parsing
of arbitrary textfiles is an ugly thing to do ... But if you like this
more *shrug* do it ^^

- - Nec
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGo+Dm4UOg/zhYFuARAvNBAJ9mEP0+mGpfDuCo8BjYxer9TWPAHQCbBNDe
fYXntQRaiNMFxnQv+FIFjyg=
=61SD
-----END PGP SIGNATURE-----
-- 
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[David Shakaryan]

Marijn Schouten (hkBst) wrote:
> Can't we already (automatically) remove masks for which the relevant 
> ebuilds have been removed? Is there another situation for which you 
> think this is useful?

While it might be possible, we currently aren't doing that. It shouldn't 
be too difficult to implement, but it would have to be semi-smart and 
check if that package ever existed, as some developers add masks before 
adding packages and we don't want those automatically removed.

I have a simple script that outputs all masks that aren't actually 
masking anything. I run it every once in a while and remove such masks 
(after, of course, looking at the comments), and this has been working 
fine so far.

-- 
David Shakaryan
-- 
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[René 'Necoro' Neumann]

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

Alec Warner schrieb:
>> It has been a proposal only ... :) As I thought that automatic parsing
>> of arbitrary textfiles is an ugly thing to do ... But if you like this
>> more *shrug* do it ^^
>>
>> - - Nec
> 
> And the alternative to parsing arbitrary text files is?  Why do you
> think it's ugly?
> 
> -Alec
> 

It is ugly, because you have to write an (error prone) parser by
yourself instead of using a generic one (for XML, sexps or whatever).
And it is easier to format the file in a wrong way and thus leading to
sth unwanted ...

But I don't think, this discussion leads somewhere ... (sorry that I
brought that topic at all). In the end it's the decision of the poor guy
who has to do the work :)

- - Nec
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGpDvk4UOg/zhYFuARAkRQAJoD4kXoG1sBnHxvIYQ6EKHPRii/ogCeOOxk
AXDAYTywLoRAs4EBQTaiCTQ=
=/mFL
-----END PGP SIGNATURE-----
-- 
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[Thomas Tuttle]

On Sun, 22 Jul 2007 12:38:21 +0200, "Robert Buchholz" <rbu@gentoo.org>
said:
> 3.  We could also introduce some kind of "Keywords" as in Bugzilla to 
> mark certain situations, as UNUSABLE, SECURITY, LASTRITED. Do we need 

I would particularly like this, because it's nice to know why a package
has been package.masked.  This would make it easier to decide whether I
want to unmask things or not.  (Perhaps some sort of ACCEPT_MASKED
variable could be set up, so I could choose to accept packages with
certain types of problems, with the knowledge that they might break.)

Just my $0.02,

Thomas Tuttle
-- 
Thomas Tuttle - ttuttle@ttuttle.net - http://www.ttuttle.net/

-- 
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[Robert Buchholz]

Am 23.07.2007 um 07:25 schrieb René 'Necoro' Neumann:
> Alec Warner schrieb:
>>> It has been a proposal only ... :) As I thought that automatic  
>>> parsing
>>> of arbitrary textfiles is an ugly thing to do ... But if you like  
>>> this
>>> more *shrug* do it ^^
>>>
>>> - - Nec
>>
>> And the alternative to parsing arbitrary text files is?  Why do you
>> think it's ugly?
>>
>> -Alec
>>
>
> It is ugly, because you have to write an (error prone) parser by
> yourself instead of using a generic one (for XML, sexps or whatever).
> And it is easier to format the file in a wrong way and thus leading to
> sth unwanted ...
>
> But I don't think, this discussion leads somewhere ... (sorry that I
> brought that topic at all). In the end it's the decision of the  
> poor guy
> who has to do the work :)

It's not a bad thing to do a proposal, I just don't think
breaking compatibility is worth it.

Btw, Alec: Are you sure you are subscribed here with your
scriptkitty address? Because I did not receive your last two mails
quoted by René over this list.

Robert

--
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[Marius Mauch]

On Sat, 21 Jul 2007 23:39:51 -0700
"Alec Warner" <antarus@gentoo.org> wrote:

> I wish to add a few more fields:
> 
> Effective-Date: Date the mask goes into effect.  This means you can
> mask stuff in the future.
> Expiration-Date: Date the mask ends.  This means you can have masks
> that expire after a given time.

No and no. I don't see a point in either of those, or since when is
(absolute) time a relevant factor for masking status?

> If Expiration-Date was mandatory, we could essentially have a system
> that cleans out mask files by removing expired masks.

Please provide use cases where a mask would expire at a given date and
not based on the state of the tree (analog for Effective-Date).

> Another thing I wish to address is the addition of entries in
> package.mask at the top of the file.  I think this restriction just
> makes automation more difficult.  I can't just append new entries to
> the end of the file, I have to read in the file and figure out by some
> hardcoded comment strings where the actaul masks begin, and then
> insert text right below the examples.  This is horrible.  Can we nuke
> that convention, why are new entries at the top?

I think that convention comes from the fact that package.mask also acts
as a changelog for itself, and the newest entries are generally the
more "interesting" ones.

Marius
-- 
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[Alec Warner]

On 7/23/07, Robert Buchholz <rbu@gentoo.org> wrote:
>
> Am 23.07.2007 um 07:25 schrieb René 'Necoro' Neumann:
> > Alec Warner schrieb:
> >>> It has been a proposal only ... :) As I thought that automatic
> >>> parsing
> >>> of arbitrary textfiles is an ugly thing to do ... But if you like
> >>> this
> >>> more *shrug* do it ^^
> >>>
> >>> - - Nec
> >>
> >> And the alternative to parsing arbitrary text files is?  Why do you
> >> think it's ugly?
> >>
> >> -Alec
> >>
> >
> > It is ugly, because you have to write an (error prone) parser by
> > yourself instead of using a generic one (for XML, sexps or whatever).
> > And it is easier to format the file in a wrong way and thus leading to
> > sth unwanted ...
> >
> > But I don't think, this discussion leads somewhere ... (sorry that I
> > brought that topic at all). In the end it's the decision of the
> > poor guy
> > who has to do the work :)
>
> It's not a bad thing to do a proposal, I just don't think
> breaking compatibility is worth it.
>
> Btw, Alec: Are you sure you are subscribed here with your
> scriptkitty address? Because I did not receive your last two mails
> quoted by René over this list.
>
> Robert
>
>

No, gmail appears to be too stupid to pick the right address when sending mail.
I should go kick them.
--
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[Alec Warner]

On 7/23/07, Marius Mauch <genone@gentoo.org> wrote:
> On Sat, 21 Jul 2007 23:39:51 -0700
> "Alec Warner" <antarus@gentoo.org> wrote:
>
> > I wish to add a few more fields:
> >
> > Effective-Date: Date the mask goes into effect.  This means you can
> > mask stuff in the future.
> > Expiration-Date: Date the mask ends.  This means you can have masks
> > that expire after a given time.
>
> No and no. I don't see a point in either of those, or since when is
> (absolute) time a relevant factor for masking status?
>
> > If Expiration-Date was mandatory, we could essentially have a system
> > that cleans out mask files by removing expired masks.
>
> Please provide use cases where a mask would expire at a given date and
> not based on the state of the tree (analog for Effective-Date).

The best case is a last-rites mask.  Given an Expiration-Date you can
alert on masks that are old (by data) as opposed to what we do now,
which is guess based on haphazard data in the mask and whether the
package is in the tree or not.

Security masks are a subset of this and could benefit from an expiration.

We could drop the requirement of 'the package mangler expires masks
based on expiration' and just use the expiration by parsers so that
people can monitor masks and determine if/when stuff should happen.

Effective-Date has less of a use case, most people don't forget to
mask things (or if they do, it gets fixed 'real quick now').

>
> > Another thing I wish to address is the addition of entries in
> > package.mask at the top of the file.  I think this restriction just
> > makes automation more difficult.  I can't just append new entries to
> > the end of the file, I have to read in the file and figure out by some
> > hardcoded comment strings where the actaul masks begin, and then
> > insert text right below the examples.  This is horrible.  Can we nuke
> > that convention, why are new entries at the top?
>
> I think that convention comes from the fact that package.mask also acts
> as a changelog for itself, and the newest entries are generally the
> more "interesting" ones.
>
> Marius

So 'newer' correlates to 'more interesting'?
How does that mean 'new entries go at the top'?
-- 
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[Alec Warner]

On 7/23/07, Marius Mauch <genone@gentoo.org> wrote:
> On Mon, 23 Jul 2007 10:55:15 -0700
> "Alec Warner" <antarus@gentoo.org> wrote:
>
> > On 7/23/07, Marius Mauch <genone@gentoo.org> wrote:
> > > On Sat, 21 Jul 2007 23:39:51 -0700
> > > "Alec Warner" <antarus@gentoo.org> wrote:
> > >
> > > > I wish to add a few more fields:
> > > >
> > > > Effective-Date: Date the mask goes into effect.  This means you
> > > > can mask stuff in the future.
> > > > Expiration-Date: Date the mask ends.  This means you can have
> > > > masks that expire after a given time.
> > >
> > > No and no. I don't see a point in either of those, or since when is
> > > (absolute) time a relevant factor for masking status?
> > >
> > > > If Expiration-Date was mandatory, we could essentially have a
> > > > system that cleans out mask files by removing expired masks.
> > >
> > > Please provide use cases where a mask would expire at a given date
> > > and not based on the state of the tree (analog for Effective-Date).
> >
> > The best case is a last-rites mask.  Given an Expiration-Date you can
> > alert on masks that are old (by data) as opposed to what we do now,
> > which is guess based on haphazard data in the mask and whether the
> > package is in the tree or not.
> >
> > Security masks are a subset of this and could benefit from an
> > expiration.
>
> How is it useful if a masked package suddenly becomes visible again?
>
> > We could drop the requirement of 'the package mangler expires masks
> > based on expiration' and just use the expiration by parsers so that
> > people can monitor masks and determine if/when stuff should happen.
>
> How about optional generic "reminder date" and "reminder purpose" fields
> then.
>

That seems to express the intent well, I'll bite ;)

> > > > Another thing I wish to address is the addition of entries in
> > > > package.mask at the top of the file.  I think this restriction
> > > > just makes automation more difficult.  I can't just append new
> > > > entries to the end of the file, I have to read in the file and
> > > > figure out by some hardcoded comment strings where the actaul
> > > > masks begin, and then insert text right below the examples.  This
> > > > is horrible.  Can we nuke that convention, why are new entries at
> > > > the top?
> > >
> > > I think that convention comes from the fact that package.mask also
> > > acts as a changelog for itself, and the newest entries are
> > > generally the more "interesting" ones.
> > >
> > > Marius
> >
> > So 'newer' correlates to 'more interesting'?
> > How does that mean 'new entries go at the top'?
>
> at the top => less scrolling when reading the file manually
> more interesting (newer) => read more often
>
> Mind that convention is from the days when portage didn't display
> actual masking status or the comments from package.mask, so people had
> to read package.mask manually if they wanted that information.
>
> Marius
>

Aha, see that makes lots of more sense with historical context...

Is there a reason to continue the trend?  I am unaware of many tools
to write package.mask entries..although echangelog manages to put text
at the top of the changelog, I still think append is much easier ;)

-Alec
-- 
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] Automation: Making package.mask better

[Kumba]

Alec Warner wrote:
> 
> Is there a reason to continue the trend?  I am unaware of many tools
> to write package.mask entries..although echangelog manages to put text
> at the top of the changelog, I still think append is much easier ;)

At the top is what I've always seen done.  Means all you have to do to see the 
most recent changes is simply open the file and start to read.  No scrolling to 
the end and all.  That'd be nasty with glibc, which has 16-17 changelog files 
documenting the history of that behemoth to the time before the stars themselves 
were given shape and form.

Granted, simply finding the highest-numbered changelog file, opening it, and 
scrolling to the very bottom takes just a hair more effort than just opening 
"Changelog" and reading from the top, but at that level, it's a convenience debate.


--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond
-- 
gentoo-project@gentoo.org mailing list